[dsdl-discuss] Re: Why not all of 11404? (was Re: Datatypes strawman)

 From: "Martin Bryan" <mtbryan@sgml.u-net.com>
 
> I'm not personally convinced by 11404. I don't consider things like
> complex-type and enumerated-types as primitive datatypes.

Well, that is just a wording issue. Since it seems we can map the non-primitive
things to elements

> I am also not
> certain whether I want separate types for rational, integer and real (why
> are separate types for integer and ordinal deemed relevant?) Given your
> earlier arguments that we should restrict ourselves to those thing needed to
> validate documents what would be your justification for adopting state-type
> and procedure-type when there is no event-type to accompany them?

Are they just harmless labels (like the PI attribute type in SGML)?

But it is obvious from the way the wind is blowing that the more we
can provide high-level declarative schemas the more useful DSDL
will be. So I guess I am just wondering if the aggregate type in
11404 represent low-hanging fruit that we can take advantage of,
so that we don't need to elaborately jsutify our every choice but say
"we are adopting 11404".

> But is the ordinal-type defined in 11404 sufficient for this? We really need
> a tree-specific set of types, such as those used for XPath, so that you can
> identify all ancestors, descendents and siblings, not just immediate ones.

Well, I think there is value in just taking an external standard and implementing
it if it is close enough. As you say in your strawman, a lot of the primitive types
seem applicable, and I added that even the complex types had utility. Whether
they all completely meet the needs is a good question; I tend to think that
knowledge of whether an element's contents are ordered is pretty important.

There is an alternative story too, I guess. We could say that if elements
are supposed to be ordered, they should have been declared ordered in the
RELAX NG schema. If the schema says interleave, then we can treat them
as unordered. I don't like that option, because it confuses the lexical and
the semantic.

> Storage does not take place until the XML Schema has been fully applied. You
> store the DOM resulting from schema validation. In converting from the DOM
> to the database schema the set of rules for walking the DOM are specific to
> the storage method, not in any way related to the parsing/validation stage
> that precedes it.

There is talk in some group somewhere of removing some axes from some
specification because of this very implementation issue.
 
> >1) Ignore it. Who cares about RDBMS efficiency! This is the view
> to which I tend, but I expect others have different interests.
>
> If DSDL can be implemented without too much hassle on RDBMS systems it will
> have a wider market, even for inefficient tools.

Yes, which is why I think it is worthwhile considering.
 
> >2) Implement some version of RDF Schemas. I don't believe that
> RDF (Schemas) is mature enough for us to use at the moment. Dave Becket
> has been doing a wonderful job pulling it into shape however.
>
> God forbid: lets keep away from the RDF minefield. We don't want to be hurt
> when it explodes :-)

:-)

> >3) It is interesting that the 11404 includes things like bag and set.
>
> If RDF Schemas is not mature enough then the draft status of the untried
> 11404 is even more likely to raise concerns. Among the quesions I would need
> to get answered (given that I have only quickly flicked through the text)
> are: Is set ordered? Is it restricted to a single type? Can sets contain
> bags, or vice versa?

All good questions.

> >Why not say:
>
> 1) Element values and attribute values can be validated as 11404 primitive
> types.
> 2) Elements with mixed or element content can be validated as 11404
> aggregate types
> 3) Then we need to figure out whethe the other generated types fit in.
>
> >This gives us a very strong ability to map from document to data
> structures.
>
> OK folks, Rick wants to use the full set of 11404 types, and nothing else,
> while I prefer to have a restricted set of primitives with other types that
> are specific to DSDL, including all the basic SGML-related types. We need
> more feedback from the lurkers on the list before we can determine which way
> to jump. Shout out soon, or you'll be forced to use 11404 or my simple
> subset. You have been warned!!

I don't know if I want to use nothing else! My view on which primitives are
appropriate will be affected by whether the framework
allows fragmenting complex values (a la Regular Fragmentations)

So I would say we can provide a couple of sets, so the user picks
  1) XML (or even SGML!) datatypes, or
  2) 11404, or
  3) an extension, in particular XML Schemas datatypes.

XML Schemas used

  * Java +
  * SQL +
  * DTD +
  * 11404 (subset) +
  * ISO 8601 (subset) +
  * a couple of additions
and this results in a pretty arbitrary set. I think James' argument is that
anything is arbitrary, so the ability to choose is more important.

Is there a version of 11404 available online?

Cheers
Rick

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)