[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX Filters for Namespace Processing
- From: Jeff Rafter <jeffrafter@earthlink.net>
- To: Ronald Bourret <rpbourret@rpbourret.com>
- Date: Sat, 04 Aug 2001 13:04:03 -0700
> Not true. If you transfer the fragment with DOM, the namespace
> information is carried along. This is only true if you transfer the
> fragment with a text editor. As many threads on xml-dev have shown,
> text-based processing of XML is hazardous at best.
That is my point-- within DOM (or even a SAX filter) if the fragment is
moved that namespace (or in this case lack-thereof) *should* be carried
along as well. For example
Source DOM
=========
<person xmlns="http://simonstl.com/person">
<givenName>Chip</givenName>
<familyName>Skillet</familyName>
</person>
Dest DOM
========
<otherdoc xmlns="http://simonstl.com/otherdoc">
</otherdoc>
If the givenName and familyName are moved into the "Dest DOM" they shouldn't
suddenly have their namespace changed to http://simonstl.com/otherdoc simply
because they are using the default. The entire QName tuple should be
moved-- or in the case of a prefix confilt a new prefix may be chosen (as in
the namespace filtering AElfred's NSFilter has does) and the namspaceURI and
local part should remain as they are (DOM2 does not allow/require prefix
generation in memory though serialization may vary). In either case the
prefix is syntax sugar. To demonstrate:
Source DOM
=========
<p:person xmlns:p="http://simonstl.com/person">
<p:givenName>Chip</p:givenName>
<p:familyName>Skillet</p:familyName>
</p:person>
Dest DOM
========
<p:otherdoc p:xmlns="http://simonstl.com/otherdoc">
</p:otherdoc>
Even if they were all prefixed-- does the prefix control what the resulting
namespace is if the fragment is moved? No, it is just a shortcut.
Therefore the processing should work the same when moving an unqualified
block. The DOM shouldn't care what the namespace is-- it should just be
string matching.
The fact that some do/might coerce the fragment frightens me. The reference
for appendChild makes no case either way and importNode says that the
prefix, namespaceURI and localName are to be duplicated-- not modified.
The major treatment of this is found in [1]:
"However, nodes are permanently bound to namespace URIs as they get created.
Consequently, moving a node within a document, using the DOM, in no case
results in a change of its namespace prefix or namespace URI."
[1]
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Namespaces-Considerations
Regards,
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting
>
> -- Ron
>
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org