Let us play the name space game. Options

[kgun]

This post:

Can we have multiple target namespaces for an XSD file

inspired me to write the following, that I hope will clear some misunderstandings if you can answer 90 % of the questions correct:

1. What is the purpose of a name space in XML documents?
2. What is a default name space?
3. Can you have more than one default name space in an XML document?
4. Where can name spaces be defined in an XML document?
5. What does it mean that a name space is a logical name?
6. What is a private name space?
7. How are attributes related to namespaces.
8. What is your comment to the following Rule: If you can, avoid using name spaces, don't use them. But if you have to use name spaces, do not use a default name space. Qualify names by using QNames.
9. This is defines an xml name space
   
   
   CODE
   <xlink: xmlns:xlink="http://www.w3.org/1999/xlink">
   
   and this defines another:
   
   
   CODE
   <xmlns:xlink="http://www.w3.org/1999/xlink">
   
   What is the difference between the two?
   
10. What is special about xml and xmlns in xml documents?
11. Give an example of a name space defined on an attribute.
12. What is a QName (qualified name) regarding name spaces?
13. What does it mean that a name space is composed of a prefix and a local name? Give an example.
14. As explaned above, this
    
    
    CODE
    <xmlns:xlink="http://www.w3.org/1999/xlink">
    
    
    is an example of how a name space is defined. What happens if millions of users start to use that name space? Will the W3C server break down?

[boen_robot]

Excuse me, but who should answer that? W3Schools? If so, this should have been in the suggestions forum. If it's suppose to be someone else that knows (like myself for example (IMG:http://w3schools.invisionzone.com/style_emoticons/default/rolleyes.gif) ), here I go:

1. To embed one XML dialect (i.e. language) into another, instead of creating another equivalent in your own language. They are also used to resolve conflicts between named nodes (i.e. elements or attributes) when two dialects define named nodes with the same names.
2. The namespace that a named node without a prefix takes.
3. Not on a single level, no. But you can override the default namespace with another default namespace at a particular element node and use that at that node and it's named nodes without a namespace prefix.
4. On any element. However, the namespace is applied only on that element and it's descendants.
5. I haven't heared that one before. I suppose it means it's not "literal" as in, it's not exactly what you see. It's more of a namespaceURI/local-name pair in which the namespace in use is resolved when the XML is parsed.
6. Haven't heared that one before either. I suppose it means a namespace that is only available for a certain child deep within the XML document, rather then from the root, in which case it's available thruout the whole document.
7. They can be in a namespace too if that is the question. They are usually used without a prefix, as most dialects that use namespaces to begin with usually define their own elements that can only use those attributes. Still, if prefixed, they can also take a namespace. Otherwise, they take the namespace of their parent element (NOTE: I haven't made any tests to verify that. It may as well turn out that non-prefixed attributes use whatever the default namespace is. Still, for most dialects, that's not really a problem).
8. Processing namespaces could sometimes be cumbersome, as it requires some extra writing to ensure the namespace is your namespace. This is a guideline for ease of use on custom dialects used in your own application(s) only. However, I could say another guideline - "Use a standart XML language when one is available for your task and only create a dialect of yours if there isn't. If you do create your own dialect, make sure you give it a namespace of your own so that it could be smoothly embed in other documents.
9. Both are wrong. The second could exist as part of an element, but not like that. And for the first... Typo?
10. The string "xml" at the beginning of named nodes is reserved for special things XML may standardise. That was clear ever since the first edition of XML. When XML namespaces came into the game, W3C used that rule to standardise XML namespaces as part of the core XML language. So, namespaces (The "xmlns" "attribute") is special in that it is part of the core language, rather then being an custom attribute of yours or anything like it. In addition, every XML document predeclares the "xml" prefix for named nodes that are part of the core language. Such include "xml:lang", "xml:base" and "xml:id".
11. The xsl:use-when attribute in the example below uses the XSLT namespace URI with the "xsl" prefix defined on the same element
    
    CODE
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xsl:use-when="system-property('xsl:version') = 2">
12. A namespaceURI/local-name pair.
13. Look above. Prefixes are not even mandatory. Wihout a prefix, the specified namespace becomes a default namespace.
14. A namespace URI (Uniform Resource Identifier) is only an identifier, not a location the language processor will look into. Because of that, W3C's servers will never crash since they don't even get connected to for that. For example, even though the URIs "http://www.w3.org/1999/xlink" and "http://w3.org/1999/xlink" resolve to the same location, they are different URIs (look at the missing "www" in the second) and an XLink compliant processor won't interpret XLink nodes using the second namespace as it's not the same identifier XLink has defined as it's namespace.

[kgun]

First of all there is a relation between question 5 and 14. Name spaces are used to eliminate ambiguities and make elements and attributes unique. Name spaces are created using a special prefixed name and a URI like this:

xmlns:prefix="URI".

I am in a hurry, before I comment on each answer I will come back and post a cryptical example that may make the points clearer.

Though, I hope for a deeper discussion, if possible, before that is done. Understanding and using name spaces correctly can save you hours / days and weeks of frustration working with your XML documents, your native XML database (NXD) or XML CMS.

[boen_robot]

Yes. Examples. I forgot about that. Sorry.

Namespaces may become more clear if you imagine each XML document as a namespaceURI/local-name pair, as it's truly is. For theese examples, let us mark namespaces with "{namespaceURI}" and omit the namespace declarations.

Regardless of the prefix you use, or if you don't use a prefix at all, what matters is the URI at the end.

So, the following two XMLs:

CODE

<root xmlns="http://example.com" xmlns:f="http://w3.org">
  <f:element/>
  <myElement>
    <f:myElement/>
  </myElement>
</root>

CODE

<f:root xmlns:f="http://example.com" xmlns="http://w3.org">
  <element/>
  <f:myElement>
    <myElement/>
  </f:myElement>
</f:root>

are both resolved to:

CODE

<{http://example.com}root>
  <{http://w3.org}element/>
  <{http://example.com}myElement>
    <{http://w3.org}myElement/>
  </{http://example.com}myElement>
</{http://example.com}root>

NOTE: the last one is just shown like that for clarity. It is NOT how XML documents look like when open or parsed.

And the following example shows how are default namespaces resolved when within the document.

The XMLs:

CODE

<f:root xmlns:f="http://example.com" xmlns="http://w3.org">
  <element/>
  <f:myElement>
    <myElement xmlns="http://example.com">
      <element/>
    </myElement>
  </f:myElement>
</f:root>

Resolves to

CODE

<{http://example.com}root>
  <{http://w3.org}element/>
  <{http://example.com}myElement>
    <{http://example.com}myElement>
      <{http://example.com}element/>
    </{http://example.com}myElement>
  </{http://example.com}myElement>
</{http://example.com}root>

Notice how the non prefixed myElement element and it's child element node are now in the http://example.com namespace, even though they are without a prefix. That's again because it doesn't matter what prefix you use, if any, as long as the final outcome is what you want.

[kgun]

I am still in a hurry on, holliday away from my own computer.

Great. I will study your code in more detail.

Thoughts:

What about collision of (short) namespace names? How to avoid that? In C++ there are two solutions, using-declarations and usning-directives where the first is more specific. What about name space aliases. Note, in C++ a class is a name space, but a name space is not a class, among other things because a name space is open in C++.

What about nested name spaces?

A::B::x where A and B are name spaces.

Is the global name space :: the same as the (a) default name space?

[boen_robot]

Depends on what you mean by short namespace names.

If you mean short prefixes, again, the prefix is irrelevant, as long as the URI is the same. So even though XSLT stylesheets usually use the "xsl" prefix, you can safely use "whateverPrefixYouWant" as prefix, provided it's still pointing to the XSLT namespace URI.

If you mean short URIs. That's very unlikely, as language authors usually use their own domain for namespace URIs. It's unlikely that anyone else would want to use your domain instead of their own (which doesn't even have to exist to begin with anyway). Why would you for example create a dialect that uses the "http://microsoft.com" namespace, when you could use "http://yourDomain.com" instead?

There are no nested namespaces in XML. There are nested namespace declarations, which override any previously defined namespaces (there are examples on that above), but there's no inheritance. The reason is simple - simplification (pun intended). Oh, and portability too (being able to insert one language into another without explicitly defining that you expect it).

[kgun]

There are no nested namespaces in XML. There are nested namespace declarations, which override any previously defined namespaces (there are examples on that above), but there's no inheritance. The reason is simple - simplification (pun intended). Oh, and portability too (being able to insert one language into another without explicitly defining that you expect it).

To follow up the discussion, before a summary is written in x posts. The cryptical example will be given in y posts.

1. What do you mean by a target name space in an XSD schema?
2. Why and how do you use include to combine separate schemas into a master schema?
3. Why and how do you use import to combine separate schemas into a master schema?
4. What do you mean by a name space attribute on elements in a schema and which rules apply to this attribute?

The following cite is from Robert Richards (2006) "Pro PHP XML and Web Services" page 100.

"XML schemas have great extensibility - not only using user-derived types but also from nested include and import possibilities."

What does he mean?

[boen_robot]

1. A single schema file can only specify what's legal at a certain namespace. The target namespace is the namespace for which you specify what's valid. For example, in the schema for XLink in this post, you'll see the target namespace is http://www.w3.org/2000/10/xlink-ns, which is XLink's namespace (speaking of which, what's really XLink's namespace? Yours, that or what?).
2. If the schema is too large you might want to place it in a few parts. Other reasons could be that one schema file will define your custom datatypes (what kind of contents is legal for a certain node), while the other one will define the legal attributes and a third one the legal elements. That's all just an example though. You decide what and why to include. I'm not sure if it has any other uses.
3. You can use xs:import to import a schema for another namespace. This allows a validation to automatically check both namesapces' validity, rather then only the one the initial schema is for. For example, in that same topic (and in this post to be more precise), XLink's schema is plugged into another custom dialect. A validator would validate both the dialect and XLink because it has both schemas. Without the second one, the document was either going to be assumed valid or a valid with a warning. I'm not sure if xs:import has any other uses.
4. I'm not sure I understand this one. If you mean namespace declarations in schema files, they could be used to reference an imported namespace. For example see this post, again in the same topic. If that's not what you meant, please give an example of what you're talking about.

[kgun]

I will reply later, now only collecting information. A short comment though, one obvious use of separate schema files is a large company / institution where different departments make their own schema that are consolidated into a master schema (that may be available on the intranet) at the corporate level.

To continue:
1. What does isomorphic and polymorphic mean in mathematics?
2. Give the W3C URL for
- the XML-Signature Syntax and Processing specification and
- the XML- Encryption Syntax and Processing specification.
3. What does it mean to serialize and unzerialize data? How are XML documents serialized? Name a PHP function that is used to serialize data and another that is used to unzerialize data? Can data be lost under serialization and what are the implications for XML documents?
4. What is and why is canonical XML important?
5. What is exclusive canonical XML?
6. How are namespaces treated and name space nodes processed (to canonical XML) under canonical and exclusive canonical XML respectively?
7. What is an Inclusive Namespace PrefixList parameter and how is it used?
8. What is an XML signature and what does super encryption mean?
9. On page 467 in the above mentioned book R Richards writes:

"Caution: When creating the signature document manually using the DOM API, the Signature element defines the default namespace http://www.w3.org/2000/09/xmldsig#. Elements within its scope must be created usning namespace-aware methods, such as createElementNS, in order for this to work properly."

What does he mean?

[boen_robot]

1. See Wiki:Isomorphism and Wiki:Polymorphic from Wikipedia.
2. See W3C's Signature page for details on XML Signature, Canonical XML and Exclusive Canonical XML. If you're asking for the namespace URI, it's somewhere in the corresponding specification (REC). For the XML Encryption namespace URI, it's "'http://www.w3.org/2001/04/xmlenc#", or at least the specification says so. Always search W3C when in doubht about a W3C language.
3. In order to understand that, you're going to have to face DOM in any of it's forms, ideally on a OOP S3L. I heared it a few times, but I didn't got it until I faced it. I'll try to explain it anyway...
   
   What you see when you open an XML file is not what an XML parser sees. The XML parser only uses the contents of the file to descibe the XML in it's own way. XML DOM is a standard set of classes, methods and properties for OOP languages to use to describe an XML document. When you type for example in PHP
   
   CODE
   echo DOMDocument::load('file.xml')->getElementsByTagName('title')->item(0)->nodeValue;
   
   What PHP does is not to read file.xml as is and use something like regular expressions to fetch what you want. No. It converts it to a set of objects, each of which further traversable to another. In the above example, we first begin at the document, traversing all "title" elements, then on the first one and finally outputtting it's value.
   
   An unserialized document is a DOM or another OOP representation of an XML document, specific to each XML parser. Such documents can't be written to files. They are only used by the program.
   
   A serialized document is a text representation which could then be unserialized by an XML parser.
   
   When an XML parser finishes it's work and saves it back to a text representation, it performs serialization - the process of converting the DOM tree back to text. There are certain options that affect the look of the final XML, but rarely if ever affect the further work an XML parser may have on the document. For example, PHP has an option for disabling self closing tags, so that <tag/> is always expanded to <tag></tag>.
4. As specified above, serialization options affect the output text from an XML parser. In many cases, they don't affect the normal workflow of a program. An XML that does the same thing can be written in many ways, with different serialization options and still do the same. Certain implementations however have certain extra rules about the formation of the XML, so that there could be only one XML to do one thing. Canonical XML is a set of rules for serialized documents, so that all applications that need this extra sort of precations could use a standard set of rules.
5. Honestly said, I'm only hearing from you about it now. See the pages above. I didn't understood the explanation there much.
6. Dunno. Read the specifictation if you wish. Since it's about serialized documents (rather then DOM representations), it's also user friendly enough.
7. In which language?
8. I don't know. I suppose it's a way of representing ciphered (read: encrypted) data in an XML document. And "super" encryption... I have no idea. Again, read the specification, though this time, you may find it harder to understand it.
9. Remember answer 8 from your first set of questions?
   

   Processing namespaces could sometimes be cumbersome, as it requires some extra writing to ensure the namespace is your namespace.

   
   createElementNS() is one of the many DOM methods and it's practically at the top of the list in the things I meant by saying "extra writing".

(note: you should really check out PHP's DOM reference if you're using PHP. If not, check the reference of your S3L of choise for DOM)

[kgun]

[*]In which language?

PHP.

Much noise here, especially on (exclusive) canonical XML and some regarding serialization. Under serialization, writing an XML document to a stream or a file, you may loose information / structure in the new state of the document. This is related to (exclusive) canonical XML and XML security. You find the canonical XML specification at http://www.w3.org/TR/xml-c14n that establishes a method for determining whether two documents are identical. The canonical form is very important to understand since it is related to enterprise security of XML documents. Two documents are considered identical if they have the same canonical form, even if the physical representations are not identical.

Among other things superfluous namespace declarations are removed from each element and lexicographic order is imposed on namespace declarations and attributes of each element to convert a document to canonical form.

When canoncial XML is applied to (a subset of) / the document, the serialized version may be much different. Dealing with digital signatures can become a nightmare. The original document no longer has the same canonical form even if it is the same document/subset. Trying to extract the subset and place it within a different context, such as within another document may become impossible. That is why you might also hear canonical XML referred to as inclusive canonical XML. It includes the context of a subset's ancestors. To deal with this issue, exlusive canonicalization was devised. It excludes, rather than includes, the context of a subset's ancestors. This means namespace declarations and attributes in the XML namespace from a subset's ancestors are not part of the canonicalization process when performing exclusive XML canonicalization. Read more in the above link and in Richards book chapter 12 where code examples are also given.

The minimalistic explanation of super encryption is encrypting an already (partly) encrypted document.

[kgun]

Here is the very instructive cryptical example of how confusing (default) namespace(s) scope can be in XML documents. The example is from Richards page 33.

CODE

<Order xmlns:cus="http://www.example.com/Customer"
xmlns:item="http://www.example.com/Item"
xmlns="http://www.example.com/Order">
<cus:Customers>
<Customer xmlns:cus="http://www.example.com/GENERIC_Customer">
<cus:Name>John Smith</cus:Name>
<cus:Number>12345</cus:Number>
</Customer>
<cus:Count>1</cus:Count>
</cus:Customers>
<item:Items>
<item1:Item xmlns:item1="http://www.example.com/GENERIC_Item">
<item1:Name>Book</item1:Name>
<item1:Number>11111</item1:Number>
</item1:Item>
<Item xmlns:item="http://www.example.com/GENERIC_Item">
<item:Name>Software</item:Name>
<item:Number>22222</item:Number>
</Item>
</item:Items>
<GeneralInfo xmlns="http://www.example.com/General">
<Name>General Information</Name>
<Number>33333</Number>
</GeneralInfo>
</Order>

1. Is it by coloring code, possible to explain namespace scope and scope genreally? Use two or more versions of colored code if necessary.
2. How many default name spaces are there and which one (color?)?
3. This is a small document example handling namespaces. Go back to the preceeding posts and correct any wrong answers and explain in more detail why you think the title of this post was "Let us play the name space game"? Correct or supplement other answers that you think could have been explained or answered better.

Where are other web surfers? Any other opinions on WWW?

[boen_robot]

I still don't get what you mean by that "Inclusive Namespace PrefixList parameter". Where did you saw it? Link?

Before "deciphering" the document, let me first indent it. Indentation allows you to see the hierarchy of a document, making it easier to judge namespaces too, since they are inherited from the parent element, unless otherwise overwritten.

CODE

<Order xmlns:cus="http://www.example.com/Customer" xmlns:item="http://www.example.com/Item" xmlns="http://www.example.com/Order">
    <cus:Customers>
        <Customer xmlns:cus="http://www.example.com/GENERIC_Customer">
            <cus:Name>John Smith</cus:Name>
            <cus:Number>12345</cus:Number>
        </Customer>
        <cus:Count>1</cus:Count>
    </cus:Customers>
    <item:Items>
        <item1:Item xmlns:item1="http://www.example.com/GENERIC_Item">
            <item1:Name>Book</item1:Name>
            <item1:Number>11111</item1:Number>
        </item1:Item>
        <Item xmlns:item="http://www.example.com/GENERIC_Item">
            <item:Name>Software</item:Name>
            <item:Number>22222</item:Number>
        </Item>
    </item:Items>
    <GeneralInfo xmlns="http://www.example.com/General">
        <Name>General Information</Name>
        <Number>33333</Number>
    </GeneralInfo>
</Order>

Oh, and, lol... way too much namespaces!

I got sick when even looking at them, so I wrote the following XSLT file (very quickly btw, so it may have some quirks) that resolves namespaces to the cryptic examples above. The stylesheet is this:

CODE

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>
<xsl:template match="*">&lt;{<xsl:value-of select="namespace-uri()"/>}<xsl:value-of select="local-name()"/><xsl:apply-templates select="@*"/>><xsl:apply-templates select="*|processing-instruction()|comment()|text()"/></{<xsl:value-of select="namespace-uri()"/>}<xsl:value-of select="local-name()"/>&gt;</xsl:template>
<xsl:template match="@*"> {<xsl:value-of select="namespace-uri()"/>}<xsl:value-of select="local-name()"/>="<xsl:value-of select="."/>"</xsl:template>
<xsl:template match="processing-instruction()">&lt;?<xsl:value-of select="name()"/> <xsl:value-of select="."/>?&gt;</xsl:template>
<xsl:template match="comment()">&lt;!--<xsl:value-of select="."/>--&gt;</xsl:template>
</xsl:stylesheet>

(whitespace is important!)
And the result I got with it from your XML was:

CODE

<{http://www.example.com/Order}Order>
    <{http://www.example.com/Customer}Customers>
        <{http://www.example.com/Order}Customer>
            <{http://www.example.com/GENERIC_Customer}Name>John Smith</{http://www.example.com/GENERIC_Customer}Name>
            <{http://www.example.com/GENERIC_Customer}Number>12345</{http://www.example.com/GENERIC_Customer}Number>
        </{http://www.example.com/Order}Customer>
        <{http://www.example.com/Customer}Count>1</{http://www.example.com/Customer}Count>
    </{http://www.example.com/Customer}Customers>
    <{http://www.example.com/Item}Items>
        <{http://www.example.com/GENERIC_Item}Item>
            <{http://www.example.com/GENERIC_Item}Name>Book</{http://www.example.com/GENERIC_Item}Name>
            <{http://www.example.com/GENERIC_Item}Number>11111</{http://www.example.com/GENERIC_Item}Number>
        </{http://www.example.com/GENERIC_Item}Item>
        <{http://www.example.com/Order}Item>
            <{http://www.example.com/GENERIC_Item}Name>Software</{http://www.example.com/GENERIC_Item}Name>
            <{http://www.example.com/GENERIC_Item}Number>22222</{http://www.example.com/GENERIC_Item}Number>
        </{http://www.example.com/Order}Item>
    </{http://www.example.com/Item}Items>
    <{http://www.example.com/General}GeneralInfo>
        <{http://www.example.com/General}Name>General Information</{http://www.example.com/General}Name>
        <{http://www.example.com/General}Number>33333</{http://www.example.com/General}Number>
    </{http://www.example.com/General}GeneralInfo>
</{http://www.example.com/Order}Order>

I'll let you explore the why and how after knowing what it all resolves to.

As for coloring... I started playing with the above stylesheet and I currently have an XML highlighter, but not a namespace aware one. I'll keep working on it. I'll let you know where I am when I have some progress.

The topic is called like that because a lot of the questions were about namespaces of course. Especially the ones in the first post. And why are you asking me to go back? Is this an interview or what? If it is, please let me see it when you're done (IMG:http://w3schools.invisionzone.com/style_emoticons/default/tongue.gif) . I mean a copy of the magazine or a link to the blogpost or whatever (IMG:http://w3schools.invisionzone.com/style_emoticons/default/laugh.gif) .

[kgun]

I still don't get what you mean by that "Inclusive Namespace PrefixList parameter". Where did you saw it? Link?

In one of the books I am reading of course, Richards 2006 cited above, page 457 and 459. I can cite literally what is written there:

Page 457:
"Data Model.
The data model for exclusive XML canonicalization is the same as that for canonical XML with a few exceptions. These exceptions, as previously noted, fall into the area of namespace declaration handling. You have already seen that a search of ancestor nodes not within the node set for namespace declarations and attributes from the XML namespace is not found under exclusive XML canonicalization. Serialization of namespace declarations themseleves also differs and depends upon a few factors.

You can use an InclusiveNamespace PrefixList parameter with exclusive XML canonicalization. It is a list containing prefixes and/or token that indicates a defaulit namespace. This parameter plays a role how namespaced nodes are rendered in canonical form".

Page 459:
"InclusiveNamespace PrefixList
The InclusiveNamespace PrefixList throws a little curve to the rules already defined for handling namespace nodes. A namespace node matching a prefix or token in the list is rendered according to the rules of canonical XML rather than those of exclusive XML canonicalization. Namespace nodes in the node set that match a prefix or token in the list, unlike those not in the list, do not need to have parent elements in the node set. This can make your output look a little strange because it can result in non-well formed XML, that is perfectly acceptable when generating a canonical form for a document subset."

There are examples there that make the term even more clear. In a nutshell it is about how nodes are processed during the canonicalization process. Since the canonical form is important when securing XML documents, this is important too.

You can do a lot of the canonicalization when you load the document like this:

CODE

$dom=new DOMDocument();
$dom->loadXML($xmlstring, LIBXML_NOENT | LIBXML_DTDLOAD | LIBXML_DTDATTR | LIBXML_NOCDATA);

The resulting document may still contain irrelevant nodes that may be processed before the document is in (exclusive) canonical form.

I can warmly recommed Richards book. Note it is about XML and PHP.

[boen_robot]

Heck, I'll have to read the whole book if I'm to get what he means by that.

And honestly said, I don't see why XML should be "secured". It should rely on HTTP security for transport and the application should simply process all variants it could handle. What's the deal? I really need to see a concrete example where this could be a problem.

Btw, I think I've made a neat stylesheet now:

CODE

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml">
<xsl:output method="html"/>
<xsl:param name="targetNamespace"></xsl:param>
<xsl:template match="/">
<html>
<head>
<title>Namespaces in the document</title>
<style type="text/css">
.nonTargetNamespace,pre {color:inherit;background-color:#FFF;}
.text {color:black;background-color:inherit;}
.element {color:blue;background-color:inherit;}
.attribute {color:brown;background-color:inherit;}
.pi {color:purple;background-color:inherit;}
.comment {color:gray;background-color:inherit;}
.namespace {color:green;background-color:inherit;}
.targetNamespace {color:inherit;background-color:yellow;}
</style>
</head>
<body>
<pre>&lt;?xml version="1.0"?&gt;
<xsl:apply-templates/>
</pre>
</body>
</html>
</xsl:template>
<xsl:template name="isTarget"><xsl:choose><xsl:when test="namespace-uri() = $targetNamespace"> targetNamespace</xsl:when><xsl:otherwise> nonTargetNamespace</xsl:otherwise></xsl:choose></xsl:template>
<xsl:template name="namespace">{<span class="namespace"><xsl:value-of select="namespace-uri()"/></span>}</xsl:template>
<xsl:template match="*"><span><xsl:attribute name="class">element <xsl:call-template name="isTarget"/></xsl:attribute>&lt;<xsl:call-template name="namespace"/><xsl:value-of select="local-name()"/><xsl:apply-templates select="@*"/>&gt;</span><xsl:apply-templates select="*|processing-instruction()|comment()|text()"/><span><xsl:attribute name="class">element <xsl:call-template name="isTarget"/></xsl:attribute>&lt;/<xsl:call-template name="namespace"/><xsl:value-of select="local-name()"/>&gt;</span></xsl:template>
<xsl:template match="@*" xml:space="preserve"> <span><xsl:attribute name="class">attribute<xsl:call-template name="isTarget"/></xsl:attribute><xsl:call-template name="namespace"/><xsl:value-of select="local-name()"/>="<xsl:value-of select="."/>"</span></xsl:template>
<xsl:template match="processing-instruction()" xml:space="preserve"><span class="pi">&lt;?<xsl:value-of select="name()"/> <xsl:value-of select="."/>?&gt;</span></xsl:template>
<xsl:template match="comment()"><span class="comment">&lt;!--<xsl:value-of select="."/>--&gt;</span></xsl:template>
<xsl:template match="text()"><span class="text"><xsl:value-of select="."/></span></xsl:template>
</xsl:stylesheet>

(again, whitespace is important!)
All elements and attributes that are in the targetNamespace parameter (line 4) will be highlighted in yellow. Note that their text nodes won't be. I've deliberatly made it like this, so that if a nested element is not in that namespace, it wouldn't be highlighted.

[kgun]

Heck, I'll have to read the whole book if I'm to get what he means by that.

And honestly said, I don't see why XML should be "secured". It should rely on HTTP security for transport and the application should simply process all variants it could handle. What's the deal? I really need to see a concrete example where this could be a problem.

The Https protocol may be secure enough for you, but generally not. An obvious reason, is that the xml document is still readable. For some uses that is not good enough.

Heck, I'll have to read the whole book if I'm to get what he means by that.

For some readers of this thread that may be very important. There are layers of security:

1. Application
2. Network
3. Data

Business critical processes / systems need all of them. The book is good on XML data security. That single chapter may be more than worth the price you pay for the book. Also, note that R. Richards is an PHP / XML insider that I have explained in another post on this forum.

[boen_robot]

When you send data with HTTPS, the data (as in "the XML" in this case) is encrypted. That's what HTTPS is for anyway.

I mean, just what does each of those layers protect?

1. Application - the application needs to protect itself from illegal requests that can make it do something it was not designed for, possibly interefering with third party's interests. When we talk about XML, this protection could be achieved with (carefully crafted) XML Schemas.
2. Network - when data is sent from the application to the server, it passes between routers and bridges from which the data is readable as plain text. With HTTP, the data is visible "as is". With HTTPS, the data is encrypted, meaning the network nodes see only some weird text. The server and the client decrypt the data when it reaches to them, so that it turns into what HTTP would sent.
3. Data - Network security takes care of securing the data that passes between messages. Servers may use hash strings so that even the server wouldn't carry a litteral copy of the data, but rather it's signature. That's how passwords should be stored in databases... If an attacker gets a copy of the database, (s)he still wouldn't see the password(s).

Where else does XML fit into this model? Again, I'd like to see a concrete example where there could be a problem.

[kgun]

Https=?

Secure transfer and encrypted communication?

What about a person that picks up the document on your office?

Your proposals are not secure enough for everybody readings these posts. You find a lot of real examples in the above mentioned book, that is the best I can reccomend you on PHP, XML and Web Services.

May be not the best on security, but better than many other sources.

[boen_robot]

Https=?

Secure transfer and encrypted communication?

Yes. Without it (i.e. by using HTTP), the XML is sent "as is" be it cannonical or not.

What about a person that picks up the document on your office?

There's no protection to that one in the XML. The same could happen with a cannonical XML. A username and password for the transfer (i.e. HTTP authentication) are possible solutions, but they are still done on the HTTPS layer, rather then in the XML.

Your proposals are not secure enough for everybody readings these posts. You find a lot of real examples in the above mentioned book, that is the best I can reccomend you on PHP, XML and Web Services.

May be not the best on security, but better than many other sources.

I wouldn't buy a book for a security consideration I don't see. If there's a problem and I can't think of a solution (or if I can't see cannonical XML as a solution), THEN I would buy a book to teach me on it (or more likely - find information online).

Could you give a single example from the book or a link to any online resource for it?

[kgun]

There's no protection to that one in the XML. The same could happen with a cannonical XML. A username and password for the transfer (i.e. HTTP authentication) are possible solutions, but they are still done on the HTTPS layer, rather then in the XML.

The point is that (parts of) the document is encrypted.

Canonicalization is an important part of XML enterprise security. You come a long way with basic security.

I think you can download parts of the code (may be enough) without buying the book at apress: http://www.apress.com/

Click on Books + Source Code

and scroll down to "Pro PHP XML and Web Services".

But there are much in the book that is not in that source code. I have the right to the eBook for USD 10.

You have been the only person on the WWW responding to this important subject:
If you promise to read chapter 12 on XML security and come back and comment after reading that chapter, I can buy it for you. You do not need to promise anything. You can get the right to the eBook if you want it. Then I think I must buy it and email it to you via a non secure protocol.