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:[EMAIL PROTECTED]". 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!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
