different content versions in some places in order to support all of th=
e
possibilities. I'd appreciate any feedback on why it fits or does not f=
it, or
what sucks or does not suck about it.
Be forwarned that many of the examples in the spec won't make it throug=
h this
DTD. In some cases its because of simple ordering, but mostly its just =
because
the examples were not compliant with the spec. I've passed these failur=
es back
to Ashok who I assume will update the next version. If anyone wants fix=
ed
versions of all of the examples that will also go through this DTD, let=
me know
and I'll send them to you.
Anyway, any comments on this DTD or the readability of the DCD spec or =
on DCD
in general would be appreciated. I'll make sure that they get to Ashok.=
Also,
any comments on the RDF aspects of DCD would be appreciated.
Here is the DTD:
<?xml encoding=3D"US-ASCII"?>
<!--
* FILE: DCD.Dtd
*
* This file provides a DTD for the DCD Schema, or at least for a rest=
ricted
* syntax of it that is controlled by the "syntax=3Dexplicit" Processi=
ng
* Instruction explained in section
*
* "2.1.2 Interchangeability of Elements and Attributes"
*
* This PI forces a subset of the legal properties of an element or at=
tribute
* definition to be implemented as attributes, not as nested elements.=
-->
<!--
* Define some parameter entities to simplify things below.
*
* DataTypeList
* The enumerated values for the "DataType" attribute.
*-->
<!ENTITY % DataTypeList "(id|idref|idrefs|entity|entities|nmtoken|nmtok=
ens|
notation|string|number|int|decimal|boolean|date=
Time|
dateTime.tz|date|time|time.tz|interval|i1|i2|i4=
|
i8|ui1|ui2|ui4|ui8|r4|r8|uri|char|enumeration)"=
>
<!--
* The overall syntax of a DCD Schema is that is a sequence of element=
s,
* entities, and global attribute defs. It can have a description and
* namespace declaration at the top.
-->
<!ELEMENT DCD (
Namespace?,
Description?,
(
ElementDef
| AttributeDef
| InternalEntityDef
| ExternalEntityDef
)*
)>
<!--
* An ElementDef is used to define the elements that the target XML
* file can contain, the ordering of them, and their content.
*
* Each ElementDef has an optional description, one or zero Groups, an=
d
* an open ended list of Attribute and AttributeDef elements. For the
* sake of flexibility, the content model allows as many variations as=
* is reasonable, in terms of ordering. But it does not allow all of
* the possible orderings, as it forces the description to come first.=
*
-->
<!ELEMENT ElementDef (
Description?,
(
(Group?, (AttributeDef|Attribute)*)
| (AttributeDef*, Group?, Attribute*)
| ((AttributeDef|Attribute)*, Group?)
)
) >
<!ATTLIST ElementDef Type NMTOKEN #REQUIRED
Model (Empty|Any|Data|Elements|Mixed) "Data"
Content (Open|Closed) "Closed"
Root (True|False) "False"
Default CDATA #IMPLIED
Datatype %DataTypeList; "String"
Min CDATA #IMPLIED
Max CDATA #IMPLIED
MinInclusive CDATA #IMPLIED
MaxInclusive CDATA #IMPLIED
Fixed (True|False) "False"
Length CDATA #IMPLIED
Scale CDATA #IMPLIED
Precision CDATA #IMPLIED
Picture CDATA #IMPLIED>
<!--
* An AttributeDef element defines an attribute that can be used by
* ElementDefs to define the attributes that type of element can have.=
* It can have a description and default value subelements, both of
* which are optional.
*-->
<!ELEMENT AttributeDef (Description?, Values?) >
<!ATTLIST AttributeDef Name ID #REQUIRED
Default (True|False) "False"
Fixed (True|False) "False"
Global (True|False) "False"
Datatype %DataTypeList; #IMPLIED
Occurs (Required|Optional) "Optional"
ID-Role (ID|IDREF|IDREFS) #IMPLIED
Min CDATA #IMPLIED
Max CDATA #IMPLIED
MinInclusive CDATA #IMPLIED
MaxInclusive CDATA #IMPLIED
resource CDATA #IMPLIED>
<!--
* An internal entity has a name and a value element. It is the same a=
s
* an internal entity in DTDs.
*-->
<!ELEMENT InternalEntityDef (Value?|Values?) >
<!ATTLIST InternalEntityDef Name ID #REQUIRED>
<!--
* An external entity has a name and a System Id, and an optional publ=
ic
* id. It is the same as an external entity in DTDs.
*-->
<!ELEMENT ExternalEntityDef EMPTY >
<!ATTLIST ExternalEntityDef Name ID #REQUIRED
PublicID CDATA #IMPLIED
SystemID CDATA #REQUIRED
resource CDATA #IMPLIED >
<!--
* A description is just an open ended content model, which can contai=
n
* text and desired formatting markup, but it is ignored by the DCD
* validation mechanism.
*-->
<!ELEMENT Description ANY >
<!--
* A Group is just a collection of Elements and/or nested Group elemen=
ts.
* It defines the ordering of those nested elements and groups. A grou=
p
* must contain at least one element or group or it does not make sens=
e.
*-->
<!ELEMENT Group (Element | Group)+ >
<!ATTLIST Group Occurs (Required|Optional|OneOrMore|ZeroOrMore) "Requir=
ed"
RDF:Order (Seq|Alt) "Seq">
<!--
* Attribute elements just name an attribute used by a particular elem=
ent.
* They have no content in the DCD itself, just other attributes.
*-->
<!ELEMENT Attribute EMPTY >
<!ATTLIST Attribute Name IDREF #REQUIRED >
<!--
* Element elements just name elements within a group, so their conten=
t
* is just the name of the element they refer to. So their content is
* just PCDATA.
*-->
<!ELEMENT Element (#PCDATA) >
<!--
* A name element is basically a valid name token, and a value is just=
* open ended markup.
*-->
<!ELEMENT Name (#PCDATA) >
<!ELEMENT Value ANY >
<!ELEMENT Values ANY >
<!--
* A namespace is just a URL, so we take it as PCDATA. Its validity
* will be discovered when its used I guess.
*-->
<!ELEMENT Namespace (#PCDATA) >
<!--
* The Length, Scale, and Precision values are actually numbers but we=
* can only indicate that they are PCDATA here.
*-->
<!ELEMENT Length (#PCDATA) >
<!ELEMENT Scale (#PCDATA) >
<!ELEMENT Precision (#PCDATA) >
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@us.ibm.com
=