Phil,



At 12:09 PM 8/1/2007, you wrote:
Wendell:  A useful insight into the world of XSLT training.
Its interesting that you have reservations on introducing abbreviated
XPath to students too early.

It seems to be most important that students learn that there is such 
a distinction between long and short ways of expressing the same 
XPath, not simply that they avoid short syntax. It's less confusing, 
as an early heads-up prevents them from making assumptions they have 
to unlearn later. From that it follows that it does little harm to 
use long syntax from early on, since it's more explicit.



In our regular XSLT course, we do use short syntax right away, but 
since we've also told them that a long syntax exists, it's easy 
enough to announce, when we're covering axes, for example, that "if 
an axis specifier isn't given, the child axis is assumed: that's one 
of the abbreviations that makes the short syntax".



This works well enough. What's really interesting is that sometimes 
self-taught practitioners don't even know the long syntax exists. For 
them, it's often of great remedial benefit to focus on long syntax 
early, and then once the nuts and bolts are clearly in view, to show 
how even in short syntax, they're still there, albeit hidden behind a 
nice syntactic gloss.



The problem faced by this tool (as with many) is that it has to meet the
conflicting needs of a number of different types of user. From beginners
to experts and from occasional users to freqeunt users. It may be that
I should introduce a special mode that could avoid the use of XPath
abbreviations in debugging and in auto-generation. The auto-complete
feature could also be bolstered to ensure full support for the
non-abbreviated form.

Or perhaps, just a couple of converter buttons that would take any 
expression as input and convert it into the longest or most 
abbreviated version possible. So, for example, it could take



self::node()//node()



and the "abbreviate" button would convert it into



.//node()



while the "explicate" button would convert it into



self::node()/descendant-or-self::node()/child::node()



You mention that, in training, there is no real substitute
for concrete examples. Do you know a good non-copyright resource for
such examples - preferably in xml form? One of the features of this
application is to allow the development and management of large (xml)
libraries of XPath expressions. The import feature (using a 'special'
XPath library) could make use of such a resource. Initially this would
be helpful for testing but these could also be included with the product
if and when this gets past 'Beta'state.

I wish I could help with this. Unfortunately, my experience is that 
meaningful examples are meaningful either because they're the user's 
own data or something fairly close to it, or because the user has 
already spent some time with it and worked into some credible problems.



Jon Bosak's Shakespeare in XML is a useful resource (Google to find; 
there are several copies around), but unfortunately (IIRC) the data 
doesn't have any attributes! which makes it somewhat limited for 
XPath demonstrations.



Cheers,
Wendell





======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================