Re: [xml-dev] YPath, ZPath?

[Michael Kay <mike@saxonica.com>]

> 
> On the topic of FtanML, am I the only person disappointed with the lack of
> namespaces?  

I have always considered Namespaces in XML to be a bit of a disaster, the primary problems being

(a) although it's nice to have the option to abbreviate long globally-unique names, it should always be possible to write them in full if you choose to, rather than relying on some contextual mapping of short names to long names. The fact that the long form of an element name can't be used in every context where an element name is needed adds a lot of complexity to applications.

(b) if an abbreviated form of name is permitted, then it should always be statically resolvable to the long name. This isn't possible in the case of "QNames in content", where the software component that knows the rules for converting short names to long names (the XML parser) can't detect the presence of a short name and therefore can't expand it; it therefore has to make the mapping of short names to long names available to other components in the system.

In FtanML as written up for Balisage, I proposed to tackle (a) by using long names of the form

org_w3_xsd_schema

rather than

{http://www.w3.org/xsd}schema

so that (i) the long name is a syntactically valid name, and (ii) it's rather less verbose by cutting out the verbiage of "http://"; and "www" which is just noise.

I tackled (b) by simply not provided any abbreviation mechanism, with the suggestion that long names should be used only where there really was a need for global uniqueness; for example with SVG, I think the SVG element itself requires a name like org_w3_svg, but individual elements like rectangle and circle can live happily with names whose context is established by virtue of the fact that they have org_w3c_svg as a container. 

I did consider various schemes for allowing abbreviated versions of long names but I wasn't 100% satisfied with any of them so I left this out of the paper.

Michael Kay
Saxonica