[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX Filters for Namespace Processing

• From: Jeff Rafter <jeffrafter@e...>
• To: Ronald Bourret <rpbourret@r...>
• 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@l...

• References:
  • Re: SAX Filters for Namespace Processing
    • From: Tim Bray <tbray@t...>
  • Re: SAX Filters for Namespace Processing
    • From: Jeff Rafter <jeffrafter@e...>
  • Re: SAX Filters for Namespace Processing
    • From: Ronald Bourret <rpbourret@r...>

• Prev by Date: Re: SAX Filters for Namespace Processing
• Next by Date: Re: SAX Filters for Namespace Processing
• Previous by thread: Re: SAX Filters for Namespace Processing
• Next by thread: Re: SAX Filters for Namespace Processing
• Index(es):
  • Date
  • Thread