[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Datatype constraints in DCDs

• From: "Olivo Miotto" <olivo@i...>
• To: xml-dev@i...,roddey@u...
• Date: Mon, 12 Oct 1998 10:47:33 +0800

Dean Roddey writes:

>It looks like the consensus is definitely that the more wordy XML encoding
of
>the constraint information is preferable. And I'm not too stressed out
about
>that, since I won't be the one reading them anyway :-) But I would
question the
>above scheme for enumerations. There was some desire to replace the
proposed
>DCD enumeration mechanism, but I think the above scheme would get way
wordy
>just to (for instance) check that something was one of the months of the
year,
>one of the possible XML encodings, one of the countries of the world,
etc...
>I'd definitely like to have some way to get the possible values all into
some
>slightly less versbose chunk. Even if human convenience is not an issue,
>bandwidth still remains a concern, right?

Yes, of course. And that's the reason why I hypothesized that, with
"Equals" being the default, we would have:

<AttributeDef Name="Colour" Datatype="string">
    <ValidIf value="Red"/>
    <ValidIf value="Green"/>
    <ValidIf value="Blue"/>
</AttributeDef>

which is 25% cheaper. Also, nothing stops us from allowing

<AttributeDef Name="Colour" Datatype="string">
    <ValidIf rule="OneOf" value="Red Green Blue"/>
</AttributeDef>

which requires additional parsing, but with very limited complexity. In
fact, the main issue with your proposed scheme was the need to parse a
separate syntax, but something like space-separated name lists are of
course easy to process.

The main problem I see with space-separated lists is that they do not allow
for whitespace within strings. This is ok (though not great) for
attributes, but not for elements.

>I'd almost, in the name of reuse, argue for an EnumDecl that defined such
enums
>for reuse by name, though someone might easily poke holes in that argument
>because I've not thought it out.

Actually that sounds like a very good idea, except I would do it for
datatypes, not just enum values, eg:

<DatatypeDef Name="Tristate" XmlDatatype="string">
    <ValidIf rule="OneOf" value="On Off DontCare"/>
</DatatypeDef>
<AttributeDef Name="Status" Datatype="Tristate"/>

and also

<DatatypeDef Name="RGBValue" XmlDatatype="string">
    <ValidIf rule="GE" value="0"><ValidIf rule="LE" value="255"/></ValidIf>
</DatatypeDef>

<AttributeDef Name="Red" Datatype="RGBValue"/>
<AttributeDef Name="Green" Datatype="RGBValue"/>
<AttributeDef Name="Blue" Datatype="RGBValue"/>

Hmm... just to throw ideas around- could one even have composite datatypes?
Such as

<DatatypeDef Name="Colour">
    <AttributeDef Name="Red" Datatype="RGBValue"/>
    <AttributeDef Name="Green" Datatype="RGBValue"/>
    <AttributeDef Name="Blue" Datatype="RGBValue"/>
</DatatypeDef>

And then, your ElementDef may look something like

<ElementDef Name="Background" Datatype="Colour"/>

and a valid XML tag would be

<Background Red="0" Green="255" Blue="127"/>

This is something like the AttributeGroup Concept, but somewhat more
abstract in its definition.
Regards
Olivo



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: Aggregation api used by Coins
• Next by Date: Re: ISO8601 Java utilities
• Previous by thread: Re: Datatype constraints in DCDs
• Next by thread: Re: XObjects
• Index(es):
  • Date
  • Thread