Solved

Why aren't attribute names qualifed in an XML Schema document?

Posted on 2015-02-04
11
124 Views
Last Modified: 2015-02-06
Anyone know why www.w3.org doesn't qualify XMLSchema.xsd declared attribute names in XML Schema documents?

e.g. see http://www.w3.org/TR/xmlschema-0/#POSchema:

Why not:
 
<xs:element xs:name="name" xs:type="xs:string"/>

Open in new window

instead of:
 
<xs:element name="name" type="xs:string"/>

Open in new window


I believe XMLSchema.xsd declares element names (e.g. element, attribute...) and attribute names (e.g. name, type...) as well as datatype (e.g. built-in datatype string, boolean...); so why qualify the element names and datatypes but not the attribute names?
0
Comment
Question by:SAbboushi
  • 8
  • 2
11 Comments
 
LVL 13

Expert Comment

by:Mark Bullock
ID: 40590411
I think this answers your question:  

5.1 Namespace Scoping

The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden by another namespace declaration with the same NSAttName part:

from Namespaces in XML http://www.w3.org/TR/1999/REC-xml-names-19990114/
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40590518
@markBullocks assumption is not correct

Namespace scoping only discusses child elements not attributes

Attributes are always considered in the null namespace, not the default namespace unless qualified
This implies that you can never put an attribute in a namespace without prefixing it

<foo xmlns="foo" attribute="void"><child>...</child></foo>

Open in new window

foo is in the namespace foo,  child is in the namespace foo, it inherits the declaration on foo, @attribute is in the null namespace (or in no namespace)

<foo:foo xmlns:foo="foo" attribute="void"><foo:child>...</foo:child></foo:foo>

Open in new window

foo is in the namespace foo,  child is in the namespace foo, it inherits the prefix declaration on foo, @attribute is in the null namespace (or in no namespace)

<foo:foo xmlns:foo="foo" foo:attribute="void"><foo:child>...</foo:child></foo:foo>

Open in new window

foo is in the namespace foo,  child is in the namespace foo, it inherits the prefix declaration on foo, @attribute is in the foo namespace by prefix

Note that the syntactical rules for namespaces have been spec-ed by James Clark, after the first recommendation of XML and did not form part of it (it should have been integrated actually). Namespaces were a one man effort and were easily accept as a seperate recommendation because there was an urgent need for a namespace solution

Namespaces in XML are for disambiguation. You use namespaces to indicate that a certain element is part of a certain model, a certain component you could say.
The namespace spec predates the XSD spec, so the only modelling language available at that time was DTD
In a DTD an attribute declaration forms an integral part of an element declaration, so an attribute was always declared in context of an element

From that you can understand that you put an element in a namespace,
and you put an attribute in an element
The element is disambiguated by its namespace... and the attribute is disambiguated by the actual element it is in
BUT it is not considered in the namespace of the element (that is a weird twist)

I believe that weird twist was to ensure that documents would not be overloaded with unnecessary prefixes on attributes.
If you look at your example in your original post

<xs:element xs:name="name" xs:type="xs:string"/>
  versus
<xs:element name="name" type="xs:string"/>

The first does not add real information, so it is just syntactic overhead
Note that the first is wrong simply because a schema processor expects @name in no namespace

I think it is a good decission actually
<xsl:template xsl:match="bar" xsl:mode="foo">
would make my XSLTs annoyably unreadable                              

Bottom line... only in rare occasions there is a need to assign attributes to a certain namespace
(xml:lang is a good example)

I often use qualified attributes to indicate they explicitely don't belong to the namespace of the element
(and to allow me to easily filter them out if I need to)

<foo attribute="void" ext:attribute="some info in an extension namespace">...

I hope this makes sense to you
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40590525
What I left unanswered in my previous question is why types are in a namespace

type="xs:string"

simply because types have names, they need to point to a component declaration in a schema,
the schema can have a target namespace, so you need disambiguation

type="geert:string"

now the type is a string as declared in my own namespace
0
 

Author Comment

by:SAbboushi
ID: 40594744
Thanks Mark/Geert - head spinning as I knew next to nothing about XML a few days ago...

@attribute is in the null namespace
Just wondering: is there a convention regarding the meaning of the @ symbol as you've used it in "@attribute"?


<foo:foo xmlns:foo="foo" attribute="void"><foo:child>...</foo:child></foo:foo>

Open in new window

foo is in the namespace foo,  child is in the namespace foo, it inherits the prefix declaration on foo

Doesn't the prefix declaration (foo:child) override the prefix inheritance?  I would have thought child was in the foo namespace by prefix?


<xs:element xs:name="name" xs:type="xs:string"/>
The first does not add real information, so it is just syntactic overhead
Note that the first is wrong simply because a schema processor expects @name in no namespace
It seems I'm mostly confused between what I see as two objectives with XML:
a) using namespaces for disambiguation and
b) validating an XML instance document against its Schema document.  My question just happens to be about validating a schema document (i.e. xsd) against XMLSchema.xsd

My question was prompted as I was thinking about validation, not disambiguation.  I wasn't really clear on why there was value in prefixing XMLSchema elements/attributes/datatypes in a schema until I saw the example about an element named "element" referring to chemistry and not XML... my default thinking maybe was that schema elements/attributes/datatypes are reserved words... but clearly they are not.  

So my next thought was that prefixing/namespaces are necessary for schema elements/attributes/datatypes in order for a schema validator to validate the schema... but that doesn't make sense because even if I create an element named "element", I don't believe a schema validator will have any problems with disambiguation because I believe declared elements are attribute values in a schema (e.g. name="element" for that chemistry example) and therefore cannot get mixed up with an xs: element name such as "element".

Which makes me wonder again what the purpose is of associating w3-defined schema elements/attributes/datatypes "e.g. "element", "attribute". "name", "type", "string"... i.e. schema components) with a namespace...?

Regarding my original question re: attribute names e.g. ("name", "type"):
What I think I'm slowly understanding from what you've written is this:
Although attribute names are part of a namespace vocabulary, they are local to an element.  For validation purposes (whether validating a Schema document or an XML instance document), an attribute doesn't need to be qualified because the validator knows what attribute names (e.g. "name" and "type") are valid for a given element (e.g. "element" in my example) as long as it knows what Schema document to use to validate the element.  Is that correct?

If that is correct, then that addresses the questions of "how does a schema validator know that the attribute name "name" was mispelled as "naem", e.g.
<xs:element naem="name" type="xs:string"/>

Open in new window

Is that correct?

Thanks again Geert for your most thorough answers to my various posts.
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40594814
the short form for the XPath expression for an attribute is @
it is common to use @my-att for the attribute "my-att"
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40594840
it inherits the prefix declaration on foo
a prefix has no actual meaning in XML, it is just a vehicle to bind an element to a namespace
<foo:child>...</foo:child> is illegal,
unless in a context where somewhere higher up the tree there is a xmlns:foo="..."
In my example "child" is in the "foo" namespace simply because it inherits the binding xmlns:foo="..." from its parent
"prefix declaration " is poor wording (I warned you it was late night), it is not really wrong but I think "prefix binding" makes for better understanding

When I say "prefix has no actual meaning" I really mean exactly that, a prefix only lives by the virtue of its binding and the choice of the prefix is arbitrary
<foo:foo xmlns:foo="foo" attribute="void">
<bar:foo xmlns:bar="foo" attribute="void">
<xsl:foo xmlns:xsl="foo" attribute="void">
<xs:foo xmlns:xs="foo" attribute="void">
<html:foo xmlns:html="foo" attribute="void">
<foo xmlns="foo" attribute="void">
Are all syntacticall variants of exactly the same element
And you can do all of that, though using "xs", "xsl" and "html" as a prefix for thing sother then one would expect is not so smart...
But nothing can assure us that <xs:element> really is a schema element declaration, unless there is a correct namespace binding to that prefix somewhere
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40594851
It seems I'm mostly confused between what I see as two objectives with XML:
 a) using namespaces for disambiguation and
 b) validating an XML instance document against its Schema document

They are different things though related
Consider this
- I am a developer and I am tasked to develop a schema for some calss of XML instances
- I know that my schema will be used al lot in a context with many other schema
(I happen to develop a schema for mathematical constructs, and I know it will be reused in the book schema, the brochure schema, the intranet schema, the blog schema of my enterprise)
- So I decide to use a namespace for disambiguation
- At this point a targetNamespace is a given
- So now my task is, develop an schema for validation of a class of documents / document fragments that have a namespace for disambiguation

Is that clear, they are different things, but have a relation or an impact on eachother
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40594870
I don't believe a schema validator will have any problems with disambiguation because I believe declared elements are attribute values in a schema (e.g. name="element" for that chemistry example) and therefore cannot get mixed up with an xs: element name such as "element".

Wrong, the schema validator will have a problem with disambiguating.
Note that a Schema is an XML instance of its own (in theory it could have a schema, but the existing is not complete)
If you tell the validator that it needs to use a certain schema as the schema for validating the instance, thevalidator first needs to validate the schema, though he will do that based on the specification, not necessarily by using the schema
(there are many ways to validate, schema is just one of them, and there are different types of schema, different syntax, different approach)

So, in order for the validator to "understand" the semantics of the schema, it needs to have a rigid well defined structure.
An xs:schema root, xs:element global element declarations, xs:attribute declarations, xs:type declarations
You can't use a schema for validating an instance, unless the schema follows some strict rules
(as much as a compiler can't compile a program, unless it follows soem very strict rules)

And for all of that, the "xs" prefix (some use "xsd" prefix, some use no prefix at all) needs to be bound to the right namespace
0
 
LVL 60

Accepted Solution

by:
Geert Bormans earned 500 total points
ID: 40594876
Although attribute names are part of a namespace vocabulary, they are local to an element.  For validation purposes (whether validating a Schema document or an XML instance document), an attribute doesn't need to be qualified because the validator knows what attribute names (e.g. "name" and "type") are valid for a given element (e.g. "element" in my example) as long as it knows what Schema document to use to validate the element.  Is that correct?

I would say that is close enough
0
 

Author Closing Comment

by:SAbboushi
ID: 40594967
Thanks again - much appreciated!
0
 
LVL 60

Expert Comment

by:Geert Bormans
ID: 40595315
welcome
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Preface This is the third article about the EE Collaborative Login Project. A Better Website Login System (http://www.experts-exchange.com/A_2902.html) introduces the Login System and shows how to implement a login page. The EE Collaborative Logi…
I was working on a PowerPoint add-in the other day and a client asked me "can you implement a feature which processes a chart when it's pasted into a slide from another deck?". It got me wondering how to hook into built-in ribbon events in Office.
The viewer will the learn the benefit of plain text editors and code an HTML5 based template for use in further tutorials.
The viewer will learn how to create a basic form using some HTML5 and PHP for later processing. Set up your basic HTML file. Open your form tag and set the method and action attributes.: (CODE) Set up your first few inputs one for the name and …

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now