Rick Jelliffe <rjelliffe@allette.com.au> writes:
I would cautiously observe that many 'simple' languages had thought
they didn't need a name-collision avoidance mechanism, and then had to
patch one on if/when they got successful and they started to be used
for large and/or collaborative efforts.
You only need to look at the industrial-scale XML applications such as
ebXML, UBL, RosettaNet, DITA or even ooXML to see examples of this
(some better than others, of course).
It's hard to do requirements capture after the fact, since what you
find, in the above examples and elsewhere, was of course influenced by
the mechanisms they had available. But _unless_ you study those
example and many others, you risk falling foul of one of the most
perilous addictions of the software developer: premature optimisation.
Sure.
So my minimal maximalism approach would say, what is the most we can keep from Namespaces yet maintain the other properties (of context-free parsing, etc.) How much of namespaces can keep?
From the NS infoset POV, for element and atttibute names, there is no difference between a ns bound to an element by a prefix or a default declaration. Nor one that was declared at a particular level, nor whether the prefix has been multiply defined or redefined.
So from the POV of element and attribute names, those are syntactical sugar. But that sugar is not a nice low-harm sugar (unlike, say, numeric character references, which require no context) .
So what would the problem be with removing default namespaces and only allowing 1-1 global prefix declarations? It is what XML Canonicalization does, IIRC.
There are two: the case of making an HTML file that is also an unprefixed namespaced XML document, so that existing browsers can display it. This is clearly a non-requirement for RAN (Raw Access Notation).
The second is where some documents require knowing the in-scope prefixes in order to intepret qnames in attibute values or data content. But removing the bad sugar does not prevent the qnames in content from having prefixes defined by global declarations.
So AFAICS this just means that translating existing XML documents that use qnames in content and which overload the namespace mechanism to provide the definitions for them (unlike Schematron) and which use the sugar and do have prefixes mapped differently, will require adjusting the prefixes of the qnames in content.
It is not as if allowing qnames in content with the XML Namespaced syntactical sugar actually allows easier fragment or value transplanting, or anything. If I cut a value with a qname in content and put it elsewhere where the same prefixes have different mappings in scope, I have to adjust the prefixes in that content anyway.
The latest version of RAN is up at
www.schematron.com. An interesting update is that the date datatype now has extensions from ISO8601:2018, for intervals, wildcarding, and uncertainty.
Regards
Rick
