[Dev] Proposal: simplify parcel XML namespaces

[Phillip J. Eby]

At 11:22 AM 6/27/2005 -0700, Bryan Stearns wrote:
>I registered my objection to warn that using non-URI namespace names 
>risked future conflict ("http://a.domain.the.author.owns.org/whatever" has 
>no risk of conflict, where switching to "parcel:something" risks a 
>conflict). Lisa pointed this out as well. However, Katie said,
>
>>Parcel xml is only a local file format, read only by the parcel loader. 
>>Any pretentions to other uses have fallen by the wayside.
>
>so my warning is moot (and supporting http namespace names for backward 
>compatibility isn't important).

Also, the parcel loader doesn't accept "foreign" namespaces *now*.  That 
is, any xmlns declaration is treated as an attempt to refer to or depend on 
a known parcel, and any use of that namespace is then expected to refer to 
items in that parcel.  So the only way you could use some other kind of XML 
content in a parcel.xml would be if you created a parcel for it.

To put it more specifically, let's suppose I wanted to embed some XHTML in 
a parcel.xml file.  The only way I could do this was if I created a parcel 
using the XHTML namespace, and then defined a *schema* for items 
corresponding to XHTML elements!  However, such an effort would be doomed 
to failure, because the parcel loader has its own expectations about 
attributes, structure, etc., that wouldn't be able to handle the generality 
of XHTML.

Thus, the possibility of conflict with some other "parcel:" XML namespace 
is moot because there's no way you could get that hypothetical conflicting 
namespace to work with the parcel loader *now*, even though you can 
currently give your parcels whatever namespace you like.

(Ironically, by going with "parcel:", we actually would make it *possible* 
to have such other non-parcel.xml content (e.g. embedded XHTML), because 
the parcel loader could then ignore anything but namespaces mapped to 
"parcel:" URIs.  :)  But I still don't see any use cases for allowing that.)