Re: [xml-dev] A Namespace Proposal

[Mike Sokolov <sokolov@ifactory.com>]

On 12/14/2010 06:41 AM, Pete Cordell wrote:
>
> My main reason for adding the alias was concern about cases where 
> there wasn't a heuristic mapping of 'legacy' URI based domain names 
> into reverse domain names.  I'm not totally sure how much of an issue 
> this is, but I think http: based URI schemes allow characters that are 
> not valid XML name characters.  Then there are other URI schemes such 
> as urn: and presumably others.  Plus people may make up their own 
> schemes as the namespace is in general just a string.
Yeah, my thought was that when explicit prefix mapping was necessary, 
one could just fall back to the old (xmlns:prefix=) mechanism, with the 
thought that this would be for a vanishingly small % of use cases, and 
in any case wouldn't be adding any *new* complexity.
>
> To make this worse I would like to allow for round-tripping of XML 
> with legacy URIs from XML1.0 -> XML??? -> XML1.0 such that if an 
> application parsed both XML files they would get the same results.
>
> This means you would not only need URI to reverse domain name 
> transformations, but also reverse domain name to URI transformations.  
> That seems a lot harder to me.
Right - that doesn't work with the automatic namespaces;  you have to 
fall back on explicit declarations of one sort or another.  However it 
*does* allow for XML?? -> XML1.0 -> XML??
>
>> I think it keeps too much of the complexity of the existing system in 
>> the sense that the prefix->namespace mapping is explicit, and needs 
>> to be tracked and managed as a kind of internal state.
>
> This may be a case of YMMV, but in both schemes the parser (and human 
> user) would have to maintain prefix (of some sort) to namespace 
> mappings.  In the PI case the parser is told explicitly when it has to 
> update its mappings. In the implicit case it potentially has to update 
> its mappings each time it finds a new element.  Presumably in the 
> implicit case the mappings are context dependent also.
>
Actually I now think the idea of making the declaration stay in force 
throughout the document was a good idea.  There's no reason that (even 
implicit) declarations can't have force throughout the document.  I 
don't think forward references would be a good idea, but following nodes 
could certainly make use of prefixes brought in scope on previous nodes.
> I also think the PI method would be easier for a user.  They can use 
> the logic, if the prefix doesn't have any dots in it then its an 
> alias, and they just have to check the section of the XML that 
> specifies the mappings to work out what the full namespace is.  With 
> the implicit scheme they potentially have to back track through each 
> element all the way to the beginning of the data.  This may take a 
> while and is likely error prone.
>
It is nice to centralize the declarations - it wasn't clear to me that 
this was enforced though.  Couldn't the user pepper the PI's throughout 
the document?

> I do like a recognisable separator such as a ":" between the namespace 
> part of the name and the local part of the name.  You did include that 
> in your earlier example, so I'll assume that gov.nyc.law.case is meant 
> to be gov.nyc.law:case.  (Let me know if I'm wrong.)  Making that 
> change and removing the ambiguous example, comparing your example 
> using the two schemes side-by-side, you get:
Yeah - the ":" was an unconscious omission.  I like it too.  I agree 
that resolving ambiguity is the worst part of the implicit hierarchical 
prefixes, but my point was mostly that it's not actually that bad, and 
that it doesn't arise very often.  I do agree that explicit declarations 
are neater in that instance.  I just think they come with other baggage 
(mainly a new syntax to learn, and prefix declaration separate from the 
tags that use it).

-Mike