[Dev] Proposal: simplify parcel XML namespaces

[Phillip J. Eby]

At 11:21 AM 6/27/2005 -0700, Lisa Dusseault wrote:
>To avoid conflict, wouldn't a 3rd-party instead use a URI of the form 
>"http://www.mydomain.com/whatever", with whatever their registered domain 
>is?  Or are you saying somebody working on one of the shipping product 
>schemas (one of us or a volunteer on the main codebase) would use the HTTP 
>scheme?

The latter.  However, in thinking this out to answer you, I see that my 
backward compatibility idea was broken.  The problem is that if somebody 
needs to use a "parcel:" scheme URI as an XML namespace and does *not* want 
Chandler to interpret it as a parcel reference, the whole scheme breaks 
down per Bryan's comments.


>If we use XML namespaces, I am not sure we can restrict the types of 
>namespaces used.  Since any URI is legal, a 3rd-party developer could put 
>"urn:ietf:params:xml:ns:foo" (which does use a legal scheme ) or even 
>"mailto:dev at mydomain.com".  We can lead by example, is all...

Right, but Chandler won't do anything special with anything but parcel: 
URIs, so this isn't an issue.

IIRC, we already decided to take away the ability for parcels to define 
their own namespaces, as this is a waste of time where uniqueness is 
concerned; there is no reason to make people make up two unrelated names 
for the same thing, especially if only one of them can actually provide 
uniqueness.  So, the only use for non-"parcel:" URIs in parcel.xml is if 
you are including some content that Chandler should *ignore*, and that will 
work fine.

Hm.  After doing some research on that last sentence, I find I'm wrong, but 
in a different way.  The parcel loader tries to understand *all* XML 
namespaces in a document.  Therefore, it is impossible now to use some 
"non-parcel" XML namespace in parcel.xml now!

So, the hypothetical conflict can't possibly occur with today's parcel 
loader, because it won't let you use a namespace that doesn't correspond to 
a known parcel!