Re: Lists of simple datatypes

[Eric van der Vlist <vdv@dyomedea.com>]

Before discussion list of simple data types, I'd like to raise the
question of the usage of a namespace prefix in a value:

<element name="number" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
  <data type="xsd:integer"/>
</element>

I think this construct isn't clean since it's creating a relation
between a namespace prefix and the content of an attribute.

I know that it has been used by a number of applications, including XSLT
(but there, the context was different since the namespace declaration
was already needed for the literals) and W3C XML Schema.

Without starting a long rant, I think that, in the case of W3C XML
Schema, this is an error and that we shouldn't be following them.

I would rather use something like:

<element name="number">
  <data type="integer" role="http://www.w3.org/2000/10/XMLSchema" />
</element>

(or type-system instead of role ?)

or, if we want to support user defined data types with the W3C XML
Schema system:

<element name="number">
  <data type="integer" 
	role="http://www.w3.org/2000/10/XMLSchema" 
	namespace="http://www.w3.org/2000/10/XMLSchema" />
</element>

Leaving the possibility to write:

<element name="number">
  <data type="foo" 
	role="http://www.w3.org/2000/10/XMLSchema" 
	namespace="http://example.org/ns/bar" />
</element>

James Clark wrote:
> 
> At the moment, TREX does not allow things like:
> 
>   <zeroOrMore>
>     <data type="xsd:integer"/>
>   </zeroOrMore>
> 
> There is a fairly obvious semantic that could be given to this: it would
> match a list of zero of more integers separated by whitespace.  This is
> the same semantic as "list" in W3C Schemas.  I believe the XML Query
> Algebra takes this approach: it uses the normal sequencing operators to
> model XML Schema list simple types.
> 
> It is not entirely trivial to make this work, both from the point of
> view of the formal specification and from the point of view of the
> implementation. There would definitely be a complexity cost in making
> this work.
> 
> One benefit of this might be to allow us to have a simpler interface to
> the datatyping vocabulary.  XML Schemas offers 3 ways of deriving new
> simple types: union, list, restriction.  TREX can already handle union
> (it's the same as choice). If we can also handle list, that leaves only
> restriction.  If we only have to support restriction, we could appeal to
> an external datatype language purely for facets, rather than for ways of
> deriving datatypes.  For example, we might do:
> 
> <data type="xsd:integer">
>   <xsd:minInclusive trex:role="facet" value="10"/>
> </data>
> 
> instead of
> 
> <data type="xsd:integer">
>   <xsd:simpleType trex:role="datatype">
>     <xsd:restriction base="xsd:integer">
>       <xsd:minInclusive value="10"/>
>     </xsd:restriction>
>   <xsd:simpleType>
> </data>
> 
> Better yet if we could find a way to make:
> 
>   <data type="xsd:integer" xsd:minInclusive="10"/>
> 
> work.  I think this would be significantly easier to learn and use than
> the current syntax.
> 
> Is this an avenue of development worth pursuing?

The list mechanism, or the alternate syntax for W3C XML Schema part II ?

It's probably a very personal opinion, but I am not very keen of list
data types. For me it's like defining a non XML structure within text
nodes or attributes. This is asking 2 questions:

1) is it fair to facilitate the definition of such structures if the XML
API and data models do not support them ? 

A simple whitespace separated list is, for instance, much more difficult
to access using XSLT/XPath than XML nodes (and it's also the case if one
would like to access them using only SAX or DOM APIs).

2) if we want to do this, why would we limit ourselves to a list of
whitespace separated values having the same data type ?

Comma separated lists would be nice also. And it could also be
convenient to handle a non standard date format as a "/" separated list
of 3 values having different types. .../...

I wouldn't make supporting lists a top priority, thus.

If it's more than lists, defining a bridge between TREX and datatyping
systems would be real nice.

I think, though that we should try to make sure the data typing system
is plugable (thus my proposal to add a "role" or "type-system" attribute
to identity the type system.

The lack of an abstract type system is IMO a significant flaw with W3C
XML Schema Part II since it means that you cannot define a really new
type system nor dissociate what they call value space from the lexical
space. That's why there are so many primitive data types and also why
you can't localize the decimal or date types.

I hope someone will tackle these issues before W3C XML Schema 2.x and I
think we should be independent enough from the data type system to be
able to plug any other proposal if this happens...

Eric

> James

-- 
See you in Austin (Knowledge Technologies 2001)
              http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------