RE: SD3 - Data Types

Matthew Fuch's raises an important question: If there are data types,
are they part of the XML language definition or in a standard library?

What I had in mind with data types was that the XML language definition
would only go so far as to say: There is an attribute "xml-type". Its
value is the name of an element type. Its effect is to subclass the
contents of the element. 

For example, if an element's contents are ANY or MIXED, an xml-type
attribute might identify it as actually being a date, in a standard
format such as ISO 8061. This separates the semantics (e.g. "Due Date")
from its representation ("ISO 8061 date").

I imagine that the language definition will not in fact define the
element types, but that these will be defined in some standard schema
that will be broadly shared.

> -----Original Message-----
> From:	Matthew Fuchs [SMTP:matt@wdi.disney.com]
> Sent:	Friday, May 16, 1997 12:43 PM
> To:	Dave Hollander; w3c-sgml-wg@w3.org
> Subject:	Re: SD3 - Data Types
> 
> On May 16,  1:01pm, Dave Hollander wrote:
> > Subject: Re: SD3 - Data Types
> >
> > > Matthew Fuchs
> > > ...
> > > Without questioning the importance of this issue, it strikes me as
> > > much more an application issue than an XML one.
> >
> > I don't understand this. Why would adding more datatypes to the
> > ones currently in SGML not be an XML issue? Are you saying that
> > the added types should not be standardized or that it is not up
> > to a metalanguage to provide syntax for conveying structural
> > conventions?
> >
> 
> The question is not if it's important (which it is, and therefore
> worth
> discussing), but how to support it.  Should these datatypes be part of
> the base
> language, so that all XML processors need to know how to handle them
> and it
> goes in the language definition; or does XML provide other facilities
> so that
> applications know when they're getting one of these new types, in
> which case it
> goes in an ancillary document.
> 
> If the first case is followed, then I think the DTD syntax should be
> changed to
> include them - otherwise we need extra information in the document to
> warn the
> processor.  We have two mechanisms for this - attributes and PIs.  I
> don't
> think it's a good idea for processors to start reading attributes, and
> PIs are
> obviously a controversial feature.  In either case, we're going to
> start
> polluting the namespace with what are effectively new keywords.
> 
> In the second case, we leave the processor and the language alone, and
> provide
> a standard means for expressing new types using the existing language,
> with the
> SQL set as particularly pertinent examples.  There will probably be
> many
> ministandards along these lines, kind of like architectures.
> 
> I'm sorry if I gave the impression I didn't think this was relevant.
> 
> > I think that there is a lot of value in providing additional
> > distinctions for data. I also think that the SQL basis for the
> > proposal has had enough industry exposure to make it viable
> > as a basis for standardization.
> >
> > I would like to consider how to identify other type classes.
> > Perhaps we should also provide facilities for the object domain:
> > how to identify the validation method for this object.
> >
> 
> As I said, we should think of how to express these additional
> facilities using
> XML.  To draw an analogy with C/C++, these belong in the standard
> library, not
> the language spec.
> 
> Matthew Fuchs
> matt@wdi.disney.com
> 
> --

Received on Friday, 16 May 1997 19:05:09 UTC