RE: Yet another stupid namespace question...

This problem is not limited to xmlns attributes that declare the default 
namespace. It also occurs when a default value is declared for a prefixed 
xmlns attributes. That is, how do I find the namespace used by the element 
foo:A, where xmlns:foo is declared as fixed in the schema and might have 
changed from its previous declaration?

A partial solution is as follows:

1) When reading the schema(s), keep a list of all element declarations that 
declare defaults for xmlns and xmlns:xxx attributes along with the prefixes 
and namespace URIs they use.

2) For each element you encounter, check if its base (unprefixed) name 
appears in this list. Note that a single name may occur multiple times in 
the list.

3) If the element is in the list, check if its prefix (or lack thereof) 
matches any of the prefixes stored in the list for that element.
a) If so, get the relevant namespace URI, construct the qualified name, and 
proceed normally.
b) If not, then the element belongs to the namespace according to the 
current value of its prefix (or lack thereof). If there is no match for the 
prefix (or lack thereof), then an error occurs, as this is a 
must-use-schemas scenario and no schema can be located because we don't 
have a namespace URI.

Two things to note:

1) This solution does not work in all cases. In particular, two different 
schemas can define the same prefix (or no prefix) for the same element type 
name.  There is no way I can see to resolve this situation.

2) The same process applies for prefixed attribute names, where you must 
search through the default prefixes declared by the element to which the 
attribute belongs to be sure you are resolving the attribute's prefix 
correctly. The process does not apply to unprefixed attribute names, as 
these are never part of any namespace.

A final comment is that I suspect that there should be some sort of 
requirement in the schema spec that the default value of xmlns attributes 
must match the schemaIdentity value declared in the schema.  I haven't 
fully thought this through, but it seems odd to allow a namespace URI to be 
something other than the schemaIdentity, since namespace URIs are used to 
locate schemas.

-- Ron Bourret

> ----------
> From: 	Dean Roddey
> Sent: 	Wednesday, July 07, 1999 1:56 AM
> To: 	xml-dev@ic.ac.uk
> Cc: 	Mike Pogue; heninger@us.ibm.com
> Subject: 	Yet another stupid namespace question...
>
> Ok, so I'm looking forward to implementing Schema support in XML4C/J, and
> maybe I'm missing something, but I want to make sure.
>
> Ok, lets say we have an element declaration, in Schema terms in
> this case so
> it defines both the URI and the name of the element being declared.
>
> Now, I see an element in the document content that I need to scan and
> process the attributes of. But, lets say that one of the attributes of 
the
> element, one that defines the default namespace of that element, is
> defaulted in in the element declaration's attribute list.
>
> I have to look up the element declaration in order to validate the
> attributes and/or fault in defaulted and fixed attributes.
> However, since we
> are now in the new Schema world, I have to know the full {uri}name form 
of
> the name in order to look it up, because its no longer a lexical lookup 
in
> the Schema world.
>
> But, I cannot look up the element declaration until I know the URI that
> applies to the element name. If the element name has no prefix, then it
> falls under the default namespace (which can be set by one of its own
> attributes.) But, since I cannot know the name of the element until I can
> resolve the URI it belongs to, I cannot know whether there is a
> defaulted or
> fixed attribute of that element which might set the default namespace
> (because I cannot look up the element declaration.)
>
> So, am I missing something or is this a Catch-22? Does this mean
> that Schema
> cannot allow defaulting or fixing of namespace attributes because
> of the new
> need to to logical lookup of element declarations, instead of lexical?
>
> --------------------------
> Dean Roddey
> The CIDLib Class Libraries
> Charmed Quark Software
> droddey@charmedquark.com
> http://www.charmedquark.com
>
> "100% Substance Free. Less Content, more cost. Just the way you like it"
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the
> following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
>
>

Received on Friday, 16 July 1999 08:28:41 UTC