OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] A Namespace Proposal

Original Message From: "Mike Sokolov"
> 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.

In the proposal I haven't assumed that XML??? is a subset of XML 1.0, but 
could easily be converted to XML 1.0 via some sort of shim.  Therefore I've 
gone for using the PI method of namespace alias declaration _instead_ of the 
xmlns:prefix method as opposed to _in_addition_ to.

I figure once we start making up new rules about inheriting namespaces etc., 
we no longer have an XML 1.0 subset, so its a chance to clean things up and 
make things simpler.

>> 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 like the idea of specifications being flexible, and then conventions 
constraining them.  For example, Java doesn't mandate layout and variable 
names, but convention in the shape of the Java style guide does.  This 
allows you to do things one way for 90% of the time, but allows you to break 
the rules if you need to.

So I'd say namespace definition PIs could be included anywhere, but 
convention would suggest them to be at the top.  The advantage of allowing 
them anywhere is that you can more easily glue various bits of XML together 
without doing multiple passes.

>> 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).

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS