OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: SAX Filters for Namespace Processing


I browsed through the doc and had a quick question.  Consider your example

<p:person xmlns:p="http://simonstl.com/person">

Suppose the definition of this doc was written in XML Schema.  Since XML
Schema can import namespaces, couldn't a correctly qualified version of the
doc look like this:

<p:person xmlns:p="http://simonstl.com/person"

(note that city is a different namespace).  The idea here is that the
address element is of a type that was imported from another namespace.  I'd
include the example schemas, but I am on my way home and don't have the
time. (Now I am beginning to hope that this message makes some sense ... :)

Regardless, some of the subelements might actually be from different
namespaces.  Do you have rules for dealing with this?  Are you going to tell
me to read the documentation more carefully? :-)


Peter Piatko

----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: <xml-dev@lists.xml.org>
Sent: Monday, July 30, 2001 8:35 PM
Subject: ANN: SAX Filters for Namespace Processing

> Last week at XTech (part of the O'Reilly Open Source Conference), Aaron
> Skonnard gave an excellent presentation on Namespaces.  He brought up a
> couple of issues which continue to bother me, but which have pretty much
> no single (imposable) solution.
> The first problem was the case of unqualified elements inside of
> namespace-qualified elements:
> <p:person xmlns:p="http://simonstl.com/person">
> <givenName>Chip</givenName>
> <familyName>Skillet</familyName>
> </p:person>
> I'd really prefer to see things like this written as:
> <p:person xmlns:p="http://simonstl.com/person">
> <p:givenName>Chip</p:givenName>
> <p:familyName>Skillet</p:familyName>
> </p:person>
> So, I wondered, why not write a filter that would convert from the first
> form to the second form?
> The other case involves unqualified attributes.  It's clear that the
> default namespace does not apply to attributes, but unqualified
> attributes remain somewhat anomalous themselves, not part of the element
> containing them but not necessarily a participant in the namespace.
> Things like:
> <p:person givenName="Chip" familyName="Skillet" />
> While I'm not as troubled by this as by the element issue, there are
> times (notably in RDF) where it's clearer to say:
> <p:person p:givenName="Chip" p:familyName="Skillet" />
> So again, why not write a filter?  (Thanks to Leigh Dodds for a push on
> this.)
> The two problems are very similar, and the code for the two filters is
> only slightly different.  They share a simple pair of classes for
> storing rules, and the code for the two is only slightly different.
> More details, and version 0.01 of the filters, is available at:
> http://simonstl.com/projects/namespace/docs
> This is a version 0.01, but the code is simple enough that the odds are
> good it's a solid foundation.  (Yes, I need to work on more unit
> testing.)  Version 0.02 will include RDDL documents at all the
> namespaces used.
> Also, I'm developing these filters and the Regular Fragmentations
> filters as rule-based tools running from XML vocabularies.  I'm hoping
> to modify the rule-loaders to be SAX filters, which would permit the
> combination of multiple rule sets into single documents read at a single
> parse.
> Simon St.Laurent
> Associate Editor
> O'Reilly & Associates
> ------------------------------------------------------------------
> 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