The per-element-type namespace partition

Joe Lapp jlapp at
Mon Dec 20 17:15:25 GMT 1999

I spend a lot of time creating specialized tool APIs on top of our XML parser.  This often involves taking a piece of information out of a document and running with it.  For the most part I can represent any piece with just the following:

- type of piece (eg. element, attribute, PI, comment, text, etc.)
- namespace URI (when applicable)
- local name or PI target name (when applicable)
- text (when applicable)

It seems that the following additional pieces are needed to represent attribute belonging to the per-element-type namespace partition:

- namespace URI of the associated element type
- local name of the associated element type

Since an attribute of this partition has only one associated namespace URI, you could replace the second occurrence of a namespace URI with a flag indicating that the first namespace URI actually applies to the element type local name.

Four pieces of information is already more complex than I desire.  Six pieces of information is really really distressing.  I have to find ways to keep this complexity out of my tool APIs and am looking for suggestions.

Are there any applications out there that require per-element-type namespace information?  What will I break if I effectively lump all per-element-type attributes into a single universal "default" namespace and require applications that need this information to retain information about the elements to which such attributes belong?  Why didn't the W3C just allow an unqualified attribute to assume the namespace of its owning element?  And what am I to infer from the fact that the "per-element-type partition" is defined in a "non-normative" section of the Namespaces in XML specification?

Thanks in advance for you help!
Joe Lapp              (Looking for some good people to help design
Principal Architect    and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp at 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list