Lists Home |
Date Index |
> Surely the author needs to understand the meaning of an XPath, or
> get unexpected results.
yes but if one writes an Xpath using logical unicode characters (as one
is expected to do) and this Xpath is then written out using an XML tool
to a file, then the application will write it out in any way that is
compatible with an XML parser. This may or may not use character
references and a file encoding. If the Xpath is going to be parsed by an
XML system the author needn't know or care. In the case of XSLT the
author has no control, even if (s)he does care.
However the use of XML-ish syntax in XQuery will lead people to try to
write Xquery using such tools. Sometimes it will work more or less
accidentally, but often as not it will not work. Ways of writing out the
Xpath that are equivalent to an XML system are _not_ equivalent to an
Xquery system. this is the source of the problem. It is most noticeable
in the case of character references. In Xquery, character references may
be used to "quote" any Xquery syntax construct, in the same way that
they may be used in XML to quote XML constructs. Character references
may _not_ be used this way in any Xpath that is used in XSLT (for
example) as the preliminary XML parse expands them before the XPath
parser sees them. This difference on its own (without the other concerns
re i18n and encoding) is enough to suggest that having the &# syntax in
a non-XML format is a bad idea.
> One of the design goals of XQuery is to be easily parsed using conventional
> tools like lex and yacc or JavaCC. These have no notion of the XML
> Information Set.
that is a reasonable goal, but in that case I suggest that you _only_
specify the constructor syntax and completely drop the xml-ish syntax.
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.