Solved

Is this namespace used merely to declare unique element names, or used also for validation?

Posted on 2015-02-05
10
75 Views
Last Modified: 2015-02-09
The following statement says that elements and data types "come from" the "http://www.w3.org/2001/XMLSchema" namespace.

The following fragment:    
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
indicates that the elements and data types used in the schema come from the "http://www.w3.org/2001/XMLSchema" namespace. It also specifies that the elements and data types that come from the "http://www.w3.org/2001/XMLSchema" namespace should be prefixed with xs:

I'm not sure what "come from" means here: Is this merely using the namespace to declare unique instance elements (in which case I suspect "comes from" means something like "are associated with the namespace")?  Or is this suggesting that there is a schema document at the URI that can be used to validate the XML instance document?
0
Comment
Question by:SAbboushi
  • 6
  • 3
10 Comments
 
LVL 53

Expert Comment

by:COBOLdinosaur
Comment Utility
You are partially right about documents at the URI.

This document (specifically point 1) seems to answer the question you are asking; plus a lot more information that you may or may not need for whatever research you are doing.

http://www.w3.org/2005/07/13-nsuri

Cd&
0
 
LVL 60

Expert Comment

by:Geert Bormans
Comment Utility
A "namespace" in XML is a way to disambiguate names

<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema">
is the element "element" as defined in the schema namespace

<chem:element xmlns:xs="http://www.example.me/chemical">
is a different kind of "element"

Making the distinction clear is the rational behind namespaces.
In order to make a clear distinction between the two "element",
the namespace uri needs to be different of course
This is the namespace uri in your example "http://www.w3.org/2001/XMLSchema"
Note, it is a URI, simply a unique identifyer (Uniform Resource Identifier)
It often takes the form of a URL, BUT
It does not imply that there is something to be found on that location
(URL is often chossen as the URI, simply to have some sort of guarantee that the string would be unique)

If you design a schema (or anything in XML that defines the namspace) you are free to choose the URI
Big companies have a URI naming scheme and that is exactly what CobolDinosaur gave you for the W3C
Interesting reading, but not sure that was what you are after

"come from" is a poor choice of wording. I would prefer "is specified in"
Very often you define the elements and datatypes of your XML in a schema, but they don't need to

the unique uri "http://www.w3.org/2001/XMLSchema" tels the application it is looking at an XML schema

teh unique uri xmlns:xsl="http://www.w3.org/1999/XSL/Transform" tells an application it is looking at an XSLT stylesheet

in both cases the application might or might not know what to do with it based on the namespaces
exactly the same way as a browser understands that this namespace uri xmlns="http://www.w3.org/1999/xhtml" indicates xhtml instead of html

So, it is the xmlns that tells you that the elements you are looking at are specified in a certain namespace

xmlns:xs="http://www.w3.org/2001/XMLSchema"
the (optional) part after the xmlns binds that particular namespace to a prefix that is inherited over to descendants
(allowing you to mix namespaces in one document)
That answers the second part of your question

Note:
<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema">
and
<element xmlns="http://www.w3.org/2001/XMLSchema">

have exactly the same meaning in XML terms
0
 
LVL 60

Expert Comment

by:Geert Bormans
Comment Utility
Or is this suggesting that there is a schema document at the URI that can be used to validate the XML instance document?

As said, a URI can be a URL but it does not have to
<foo:bar xmlns:foo="urn:com:foo"/> is perfectly legal

When a URL is used for the URI, often there is the documentation or an explanation at the location
just push the links found in the namespace in above post to see

referencing a schema from an XML has two components
- the namespace URI of the schema (the target namespace of the schema that is)
- the actual file location of the schema(a relative or absolute URL)
0
 
LVL 60

Expert Comment

by:Geert Bormans
Comment Utility
If I look at the title of your question, you might be looking for a short answer
Is this namespace used merely to declare unique element names, or used also for validation?

Its main purpose is to declare globally unique element names,
but some applications actually understand the semantics of the unique names
and know what to do with that
a schema validator knows what the content should be of an XML element in an instance based on xs:element
an XSLT processor knows it should copy some text to the result tree if it encounters a xsl:text
and a browser knows how to visualize a html:h1
0
 

Author Comment

by:SAbboushi
Comment Utility
Geert - thanks for all your responses.  Trying to digest them - and here's where I am:

<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema">
is the element "element" as defined in the schema namespace
Confused...: My understanding is that
1) this element declaration in an XML instance document means that the (unique) full name of the element named "element" is "http://www.w3.org/2001/XMLSchema:element" and that the sole purpose of specifying the xs: namespace is (as you said above) to disambiguate the name.
2) this element declaration has nothing to do with validation of any kind

Is this correct?

the unique uri "http://www.w3.org/2001/XMLSchema" tels the application it is looking at an XML schema
3) So this tells a schema validator to use http://www.w3.org/2001/XMLSchema.xsd not for any other reason than because anyone working with XML schemas knows that's the URL to use, even though it is not specified in the schema document?

tels the application it is looking at an XML schema
4) are there other reasons an application would need to know that other than for schema validation?

it is the xmlns that tells you that the elements you are looking at are specified in a certain namespace
5) to me "specified in" means that I can go to somewhere and see that this is so.  But that's where I get confused: I understand (thanks to your help) that the sole purpose of specifying a namespace is for name disambiguation, and my understanding is that the xlmns doesn't mean that anyone ever actually wrote a schema (i.e. there may not be "anywhere" that the element is "specified in" other than, in this case, the schema document itself).  So I don't see what is to prevent me from one day creating an xml instance document and declaring one of my domain urls as namespace where the book element is a simple type, and next month creating an xml instance document (declaring the same namespace) where the book element is a complex type.  It seems the "control" for true disambiguation is in the hands of the author?

referencing a schema from an XML has two components
- the namespace URI of the schema (the target namespace of the schema that is)
6) To make sure I'm clear, the sole purpose of the target namespace is for name disambiguation?

but some applications actually understand the semantics of the unique names and know what to do with that
a schema validator knows what the content should be of an XML element in an instance based on xs:element
7) What I'm understanding is that a schema document's file extension (.xsd) isn't necessarily relevant to a schema validator; that what is relevant is declaring the reserved namespace "http://www.w3.org/2001/XMLSchema".  If a schema validator sees this, it knows to validate the schema document against http://www.w3.org/2001/XMLSchema.xsd.  Correct?

8) Also that in order for an XML validator to validate an XML instance document, it needs the XML instance document to specify the file location of the schema document which has nothing to do with namespaces, correct?

referencing a schema from an XML has two components
- the namespace URI of the schema (the target namespace of the schema that is)
9) Not sure I understand "referencing a schema from an XML has two components- the namespace URI of the schema...".  It seems to me that just providing the schema document file location url is enough, so what am I not understanding?
10) So it seems that it is the schema that is responsible for disambiguation by specifying a targetNamespace and that the XML Instance document must also specify the same targetNamespace in order to be valid?
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 60

Accepted Solution

by:
Geert Bormans earned 500 total points
Comment Utility
1.
I am not sure I said sole purpose, rather main purpose,
it is also an indication of semantics, given that an experienced XML developer (and most of the XML tools) know what the
{http://www.w3.org/2001/XMLSchema}element is exactly

2.
In the strict sense this is correct
You have chosen the most confusing example to understand namespaces by the way
XML schema documents are XML instances themselves
so the {http://www.w3.org/2001/XMLSchema} in {http://www.w3.org/2001/XMLSchema}element
has nothing to do with validating {http://www.w3.org/2001/XMLSchema}element inside the XML instance (that by accident is a schema document)
It has to do with validation because of the fact it is a schema
It would be easier to understand on the html example
{http://www.w3.org/1999/xhtml}p has nothing to do with validation, it just says that p is specified by the xhtml specification,
or "belongs to" might be the word I was looking after earlier, given that specification can be implicit

3.
The uri value tells the schema validator that the XML document it is processing uses elements, attributes or data types from the schema namespace.
It could be a schema (it is likely a schema if it had a root element xs:schema, I deliberately simplified earlier, I told you you chose a confusing example)
A naieve implementation could use the schema your referenced indeed, though it does not cover the full specification of schema, so a validator needs to do more than just validate the schema against the schema of schemas
But you grasp the underlying mechanism. As much as a browser knows the specifics of the different html namespaces, an XML processor or validator has the knowledge about schemas built in, purely based on the namespace uri string value.

As a side note: an xslt processor can have a variable <xsl:variable name="var" as="xs:string"/> (correct namespace declarations implied here, they are usually on the root xsl:stylesheet)
An XSLT processor knows the variable is typed with a type specified in the schema specification, which is a part not covered by the schema you referenced, but documented in teh specification
I think that answers 4.
A lot of XML applications use xml schema constructs for various purposes, mainly the built in datatypes

5. If I said specified, I mean implicitely specified, never in a sense that there needs to be a schema
I often create extension elements and attributes in extension namespaces ad hoc, to stack away information temporarly to keep a workflow going and in the mean time keep the documenst valid according to fixed schemas
The specification for those are implied in the code comments
That is very ad hoc, not really robust sometimes, but completely legitimate
This is an extreme example of course
If I develop a namespace, with a longer lifetime expectation, I choose the URI very carefully and very often with the URN syntax instead of the URL syntax to avoid location expectations
urn:com:company-name:department:project:purpose
things like that will not run into ambiguous use
and if you find common constructs among schemata, yopu can seperate them out in reused components later
... control is always in the hands of the author  

6 not the sole, but the main purpose, yes
And once you understand that, you understand that it is not enough to tell a validator that a certain XML document has elements as specified in a secific namespace
If the validator needs the schema, you need a hard reference to it as well

7. Your choice of wording is obviously more careful than mine :-)
'isn't necessarily' is spot on
a schema validator will say "this is not a schema document" if the root is not {http://www.w3.org/2001/XMLSchema}schema
regardless of the filename extension
(but you know that some browsers look at the file extension first before they check the mimetype :-)

8. schema documents are related to namespaces because inside a schema document you can set the targetnamespace
A namespace does not need a schema (the xml schema for xhtml1 was useless, browsers go from the spec, not the schema)
A schema does not need a targetnamespace per se, some XML documenst have no namespace
If a schema has a targetnamespace set, the schema and the namespace are closely related

9. Often heard, the schema has a target namespace, only one per file, so yes, you could assume that the target namspace could be found in the schema
There are a whole bunge of edge cases however. I know there is a reason why we need both, but it escapes me now, 2AM here
Schema could be on a server, not accessible and then you still use the XML in well formed mode... bit vague, if you really want to know I can have a look tomorrow

10. correct, if you have a schema that goes with the namespace and you do validation, the target namespace of the schema, the namespace component in the schema refrence in the instance and the amespace declaration in the instance all need to be the same,
not a surprise, that is what binds them
0
 

Author Comment

by:SAbboushi
Comment Utility
OK - thanks for all the clarifications.

This is what I now understand:

1) XML uses namespaces:
a) as a technique to avoid  collisions of XML names, attributes and datatypes;
b) as a way to examine the meaning/use of each member of the vocabulary (if the schemaLocation is known)
c) as a means to validate XML instance documents (again,  if the schemaLocation is known)

2) the only way to insure a collision-free vocabulary is if all schema documents  sharing the same targetNamespace are examined/validated together.  The URI specified as a namespace is merely like a GUID: it knows nothing of its associated namespace vocabulary.  There is no "location" or table where elements/attributes/definitions/vocabulary actually "reside"... as a rule, I can't "go" to a namespace or a URI and see what its vocabulary actually is; in order to determine a namespace's vocabulary, we need to use that URI to assemble all the schema documents which use this URI as their targetNamespace.  The schema documents tell us the vocabulary that has been declared for that namespace (URI).  Validating all of those schema documents together tells us whether there are any name collisions (e.g. the same element declared more than once with different datatypes).

Would appreciate any final comments/clarifications on this, and thanks again for all your help.
0
 
LVL 60

Expert Comment

by:Geert Bormans
Comment Utility
1) Yes, but ... "if the schemaLocation is know" should be "if the specification is known" ... I think.
Semantics of a namespace don't necessarily require a schema... I don't think there is a valid schema for XSLT for instance
yet, XSLT has a namespace and a well specified semantics

2) In the very strict (theoretical) sense this is true. Though in realitity people choose a URL for the URI, because then they can use a domain they own, to make it unlikely that confusion arrises.
Note that complex schemata usually have a number of namespaces, multiple files, a mechanism of deriving types from other types. Plus a certain element can have exactly the same name, same namespace but different content model than another element without risk for collision if they are declared in a local context.... all of this can be a pretty complex matter... once you go down there, make sure there are company rules for using the domain in schema namespaces
0
 

Author Comment

by:SAbboushi
Comment Utility
Great - thanks again--
0
 
LVL 60

Expert Comment

by:Geert Bormans
Comment Utility
welcome
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Suggested Solutions

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…
SASS allows you to treat your CSS code in a more OOP way. Let's have a look on how you can structure your code in order for it to be easily maintained and reused.
Explain concepts important to validation of email addresses with regular expressions. Applies to most languages/tools that uses regular expressions. Consider email address RFCs: Look at HTML5 form input element (with type=email) regex pattern: T…
The viewer will learn the basics of jQuery, including how to invoke it on a web page. Reference your jQuery libraries: (CODE) Include your new external js/jQuery file: (CODE) Write your first lines of code to setup your site for jQuery.: (CODE)

762 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

12 Experts available now in Live!

Get 1:1 Help Now