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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to