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