Catégorie : XML

Uche Ogbuji asks me on the IRC:

Eric, I looked in your book for a general discussion of <data type="string"/> versus <text/>, but I didn’t find one.

It’s a question that I’ve come across a few times. I might have missed something or perhaps I and others over-think the distinction :-)

From my reading of the specs, it seems to me there is no lexical difference but that there are differences with respect to pattern restrictions (the infamous data typing restrictions in RNG), so it seems to me one should always use <text/> unless they’re sure they know what they’re doing.

Also, any thoughts about the « simple string type considered harmful » note in WXS? It seems to raise a respectable point that not allowing child elements in elements to contain prose can lead to unexpected restrictions.

That’s a common question, or if not, it’s a question that anyone writing RELAX NG or X3C XML Schema schemas should ask himself and I think that it might be useful to publish my thoughts on the subject.

The make it short, I fully agree with Uche’s analysis and here are my reasons:

The names of the elements of the RELAX NG XML syntax have been chosen very carefully and basically, <data/> has been designed for data oriented applications (or part of applications) and <text/> has been designed for text (ie document) oriented applications.

The first and best thumb rule is thus probably: if you think of the content of an element or attribute as « a piece of text » you should use <text/> and if you think of it as « data » you should use <data/>.

As mentioned by Uche, there is no lexical differences and element foo {text} and element foo {string} or element foo {token} (ie the notation of an element foo containing either text or string or token data in the RNG compact syntax) validate exactly the same set of elements. The difference is in the restrictions attached to these two patterns. The main restrictions are that:

• With the « text oriented » pattern (element foo {text}) , it is possible and even easy to extend the model to add sub elements and make it mixed content but you can’t add facets that will restrict your text nodes.
• With the « data oriented » pattern (element foo {string}) you can add restrictions to your datatype if the datatype library that you are using does support it which is the case of the W3C XML Schema datatype library, such as in element foo {xsd:token {maxLength="10"}} but you can’t extend the content model into mixed content.

Now, why do I consider string datatypes harmful?

This datatype is harmful because it doesn’t behave like any other datatype in that spaces are normalized for any datatype except string and xsd:normalizedString before text nodes reach the datatype library and left unchanged for string datatypes.

This is very different if you are applying restrictions to your datatypes.

Consider for instance: element foo {xsd:boolean "true"} and element foo {xsd:string "true"}.

The first one will accept: <foo> true </foo> while the second one will reject it and there is nothing you can do about it because the white spaces are handled before they reach your datatype library.

That’s why I strongly advise, in 99% of the cases, to use token (or xsd:token) instead of string (or xsd:string).

And don’t think that this advise applies only to cases like the preceding example where we have actual « tokens » (such as « true »). The name of the token datatype is very misleading and its lexical space is the same than the lexical space of string. In other words,  » this is a string  » is a valid token (or xsd:token) type. The difference is that if it’s a token datatype , the spaces will be normalized and what will reach the datatype library is « this is a string » .

How are these two questions linked?

The fact that <data/> is meant to be used for data oriented applications while <text/> is meant to be used for document oriented applications reduces the need to ever use the string datatype: if your spaces are meaningful, such as within an HTML <pre/> element, chances are that you’re dealing with a document oriented applications and that you should be using a <text/> pattern. On the other hand, if you are designing a data oriented applications, chances are that spaces are not significant, should better be normalized to be coherent with the other datatypes that you are probably using.

The opportunities to use string or xsd:string datatypes are thus very infrequent.

How do that translate into W3C XML Schema?

A good way to answer the question is to see what James Clark’s converter, trang, thinks about it.

If you convert a pattern such as « element foo {attribute bar {text}, xsd:token} » into W3C XML Schema, you get:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="foo">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:token">
          <xs:attribute name="bar" use="required"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
</xs:schema>

Sounds logical: a RELAX NG <data/> pattern is clearly a close match for W3C XML Schema simple types.

Now, what does happen if we convert « element foo {attribute bar {text}, text}« ? We get:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="foo">
    <xs:complexType mixed="true">
      <xs:attribute name="bar" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

And that clearly shows that the semantic of a <text/> pattern is to be a text node that has the potential of becoming mixed content model, or in other words a mixed content without sub elements!

It’s also showing a smart (and probably not used enough) option; for those of us who are using W3C XML Schema, to represent text nodes as mixed content models rather than simple string or token types in document oriented applications.

One of the things which are really hard when you specialize in XML schema languages is to play the classical « elevator story » and explain in the time it takes to go from the ground floor to your 7th floor what you are doing to own your life to your neighbor.

That’s already tough to play the elevator story explaining what is XML, just try to imagine how difficult it is with XML schema languages!

In fact, I have found that the shorter amount of time it takes me to really initiate people (that is, not my neighbors but people already knowing XML quite well) to XML Schema languages is half a day and I have made a tutorial to perform that initiation!

The next times I’ll be giving this tutorial will be on April 18th in Amsterdam for XML Europe and then on July 27th in Portland for the Open Source Conference.

I have already been giving that tutorial quite a few times at various conferences including previous issues of XML Europe, XML 2003, OSCON and even SD West 2004 no later than last month but I am still enjoying giving that talk as much as I did the first time.

As far as I know, its agenda is unique and no other tutorials or training cover all three big schema languages (Schematron, RELAX NG and W3C XML Schema).

Most of the attendees seem to enjoy this tutorial as well and to be astonished by the scope that is hiding beyond the term of « XML schema languages ». Of course, many of the concepts seem familiar to those of them who are DTD experts, but the approach taken by these « modern » schema languages is quite different and people tend to underestimate the amount of work that has been done in these areas.

I have been asked why people should want to learn about three different schema languages if they are going to use only one or two of them.

Of course, people can always learn no more than what they will immediately need, but I think that it’s a good thing to know your environment before stepping into a new discipline.

When you start learning computer science, you can start learning only a single programming language, let’s say Visual Basic, if you think that it’s the one that you’ll be using later on. I would argue that you’ll become a better programmer (even in Visual Basic) if you have an insight of other programming languages (let’s say C and Java or Python). Furthermore, you may also find out that Visual Basic isn’t always the best choice for what you’ll have to do later on.

That’s the same with schema languages. Even if right now you think that you’ll be using only one of them (let’s say W3C XML Schema), you’ll get a better understanding of W3C XML Schema if you learn about other approaches: that will help you to understand its most basic principles and also its limitations. And eventually, you may find out that W3C XML Schema isn’t always the best choice for what you’ll have to do…

See you in Amsterdam!

For one of my projects, I need to generate sample documents out of a W3C XML Schema.

I had a quick look on existing products but ruled tham out since I don’t believe they meet the requirements imposed by my customer:

• The values need to be « significant » (no « abcd » for a name).
• The schema is using some advanced WXS features such as derivation and xsi:type.

I plan to implement that as a two step XSLT transformation:

1. The WXS schema is transformed into a simplified RELAX NG schema.
2. The simple RNG schema is used to generate the samples.

The benefit of having a valid schema as the intermediate document between the two steps is that that should facilitate the debugging: if a sample document isn’t valid per the original schema, a validation against the intermediate schema should show if the bug is in step one or step two.

The reason why I have chosen RELAX NG for this intermediate schema is that it’s easier to write and easier to process but also that I can have a single schema for all the namespaces used in the original schema (that wouldn’t be possible with a W3C XML Schema).

I plan to code lists of meaningful values as WXS schema annotations and convert these annotations into RELAX NG choices so that all the alternatives (both in the achema itself and in the meaningful values) are translated into RNG choices in the intermediate schema.

Not trivial, quite a lot of work but that seems feasible to me!

Jonathan Borden has announced a version 2.0 of RDDL.

I am (or have been?) a great believer and promoter of RDDL, but I am disapointed by this version. I think that RDDL 1.0 was better than RDDL 2.0 and have sent a mail to explain why.

If you look at this example (from examplotron):

<rddl:resource
  id="xsd-schema"
  xlink:arcrole="http://www.rddl.org/purposes#schema-validation"
  xlink:role="http://www.w3.org/2001/XMLSchema"
  xlink:title="W3C XMLSchema for examplotron"
  xlink:href="examplotron.xsd"
  xlink:type="simple"xlink:show="none"
  xlink:embed="none">
<div class="resource">
<h4>W3C XML Schema for examplotron</h4>
<p>This W3C XML Schema (Proposed Recommendation, 16 March 2001)
<a href="examplotron.xsd">schema</a> describes the examplotron
vocabulary and can be imported in W3C XML Schema to validate examplotron schemas.</p>
</div>
</rddl:resource>

A link is expressed between the full description of the schema (including the whole <div/> element) and the schema.

With the new proposal you would end up with something such as:

<div class="resource">
<h4>W3C XML Schema for examplotron</h4>
<p>This W3C XML Schema (Proposed Recommendation, 16 March 2001)
<a href="examplotron.xsd"
   rddl:nature="http://www.w3.org/2001/XMLSchema"
   rddl:purpose="http://www.rddl.org/purposes#schema-validation">schema</a>
describes the examplotron
vocabulary and can be imported in W3C XML Schema to validate examplotron schemas.</p>
</div>

And the link is now between the schema and the much less significant piece of text « schema ».

And there is no way to keep the expressive power of RDDL 1.0 because the content model of the XHTML <a/> element doesn’t allow it!

The argument beyond this modification is that the syntax is simpler. That might be, but I think that it’s just not working. Yet another example of a vocabulary that should be as simple as possible but not simpler!

The other thing I don’t like is that they have used the same namespace which means that all the existing RDDL document implicitely point to the description of a vocabulary which is very different from their content.