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

The per-element-type namespace partition

• From: Joe Lapp <jlapp@w...>
• To: xml-dev@i...
• Date: Mon, 20 Dec 1999 12:16:33 -0500

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@w...           http://www.webMethods.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: The per-element-type namespace partition
    • From: james anderson <James.Anderson@m...>

• Prev by Date: unsubscribe
• Next by Date: RE: SAX2: Namespace proposal
• Previous by thread: LISTADMIN: URGENT. Delay on Transfer of this list to OASIS.
• Next by thread: Re: The per-element-type namespace partition
• Index(es):
  • Date
  • Thread