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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] xml namespace prefix resolution

[ Lists Home | Date Index | Thread Index ]

This thread seems to have gotten into HTML mode, so I'm going to back it out
to text.

From: Anirban Chatterjee
>thanks for all those who pitched in , I still dont see an easy way of
>resolving namespaces prefixes using jaxp (non parser specific api's)

That's our fault. Sorry. On xml-dev, every topic presses some smoldering hot
button. But we can be helpful on occasion. See below.

>   The only way out that I can see here is that I have to end up
>maintaining a map of prefix:namespaces for every xmlns:p="jehe"
>that I encounter in the document ,
> and use this map to resolve my prefixes ..
>   seems like something the standard parsing APIs should have
>taken care for me ..

It's not that bad. If you use a standard SAX2 ContentHandler, you will be
notified by startPrefixMapping() and endPrefixMapping() of all
prefix-to-namespace mappings. All you need to do is maintain a map of
prefix, namespace pairs and use the map when you need to get a namespace for
a prefix.

The mapping is slightly complicated by the fact that the same prefix may be
mapped to two or more namespaces in the same context, the most recent
mapping being the one in force. A simple and fast way to deal with this is
to map each prefix to a stack of namespaces. When endPrefixMapping() is
called, fetch the corresponding stack and pop it. Easy. If you ever find
yourself looking for the string "xmlns", you're doing too much work.

Bob Foster

Bob Foster <bob@objfac.com> wrote:
From: "Dare Obasanjo"
>> Because (the last time I checked) there is nothing in the SAX
>> or DOM APIs that JAXP supports that will in any sense
>> automatically resolve a namespace prefix in text contents (or
>> attribute values), irrespective that it is declared to be a QName.
>> I have to assume you know that "JAXP supports W3C XML Schema"
>> only extends to validation and you are just expressing
>> wide-eyed disbelief that all XML APIs have not extended
>> themselves to accommodate the PSVI? ;-}
>What does this have to do with the PSVI?

Only in the PSVI does a element or attribute acquire a "[type definition]"
which identifies its values as having the built-in QName type. Based on the
PSVI information, a processor can make the association between the value and
the definition of a QName as a tuple "{namespace name, local part}, where
namespace name is an anyURI and local part is an NCName", and an API could
provide the tuple to the application, rather than the lexical value.

Sure, a program using one of the standard APIs can parse the text, separate
the prefix, if any, from the local part, and use facilities provided by the
API to map the prefix to a namespace, and construct the tuple. But that's
hardly in the spirit of the original question or Henry's response to it.

>>> I want to use jaxp api's to parse into a QName .
>>I believe JAXP supports W3C XML Schema, so why isn't this just a
>>matter of writing a schema for this doc't which defines the type of
>>'elem' to be xs:QName?

Why, indeed?

>From http://www.w3.org/TR/xml-infoset/
>"[in-scope namespaces] An unordered set of namespace information items,
>one for each of the namespaces in effect for this element. This set
>always contains an item with the prefix xml which is implicitly bound to
>the namespace name http://www.w3.org/XML/1998/namespace. It does not
>contain an item with the prefix xmlns (used for declaring namespaces),
>since an application can never encounter an element or attribute with
>that prefix. The set will include namespace items corresponding to all
>of the members of [namespace attributes], except for any representing a
>declaration of the form xmlns="", which does not declare a namespace but
>rather undeclares the default namespace. When resolving the prefixes of
>qualified names this property should be used in preference to the
>[namespace attributes] property;"

True, but irrelevant.

>Of course, neither DOM nor SAX is actually based on the XML Infoset so
>it is unsurprising that they don't expose such functionality but this
>doesn't mean that it has anything to do with the PSVI.

If your comment is that DOM and SAX aren't based on the Infoset, much less
the PSVI, I agree. I hope I have made it clear how the PSVI crept into the

Bob Foster

The xml-dev list is sponsored by XML.org , an
initiative of OASIS

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription

Anirban Chatterjee
(804) 677 1916

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS