[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A Namespace Proposal

  • From: "Pete Cordell" <petexmldev@codalogic.com>
  • To: "Mike Sokolov" <sokolov@ifactory.com>
  • Date: Tue, 14 Dec 2010 11:41:41 -0000

Re:  A Namespace Proposal
Original Message From: "Mike Sokolov"

Hi Mike...

> Pete - I spent some time thinking about this too.  I'm with you in many 
> places, but I'm not sure about the PI-based abbreviation declarations.

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.

So while I can see that there might be a suitable set of rules to do the 
conversion, I don't think I (or anyone) could be sure they would work in 
100% of cases.  They are also additional complexity to explain to a novice 
user.

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.

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

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.

> ...
> This sets you up for alias name clashes.  However, I spent quite a while 
> looking for cases where namespace suffixes are shared and didn't find any. 
> I contrived this example, which doesn't seem to terrible:
>
> <gov.nyc.law.case>
> <title>Let's make a federal case out of it</title>
> <gov.us.law.jurisdiction>
>
> <!-- in the default (gov.us.law) namespace: -->
> <location>New York City</location>
>
> <!-- AMBIGUOUS; causes an error -->
> <law.case-number>123</case-number>
>
> <!-- OK; these are distinguished sufficiently -->
> <nyc.law.case-number>123</case-number>
> <us.law.case-number>123</case-number>
>
> </jurisdiction>
> </case>

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:

<gov.nyc.law:case>
<title>Let's make a federal case out of it</title>
<gov.us.law:jurisdiction>

<!-- in the default (gov.us.law) namespace: -->
<location>New York City</location>

<!-- OK; these are distinguished sufficiently -->
<nyc.law:case-number>123</nyc.law:case-number>
<us.law:case-number>123</us.law:case-number>

</gov.us.law:jurisdiction>
</gov.nyc.law:case>

and:

<?xml:nsalias nyc="gov.nyc.law" us="gov.us.law"?>
<nyc:case>
<title>Let's make a federal case out of it</title>
<us:jurisdiction>

<!-- in the default (gov.us.law) namespace: -->
<location>New York City</location>

<!-- OK; these are distinguished sufficiently -->
<nyc:case-number>123</nyc:case-number>
<us:case-number>123</us:case-number>

</us:jurisdiction>
</nyc:case>

Um, maybe a case of beauty is in the eye of the beholder :-)

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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.