today's question concerns dtd compactness
Dolin,Robert H wrote:
> Greetings XML-DEV list,
>
> We've been working on an SGML (?XML) syntax for HL7 messages,...
i've read through the related hl7sgm3 document and discovered one concern=
which
we share.
among other things the document discusses the whether attribute definitio=
ns
should be repeated as necessary or should be attached to an intermediate =
"type"
element.
where sgml permitted something like
[53x] AttlistDecl ::=3D '<!ATTLIST' S (Name | '(' Nameopt ')' ) S Att=
Def+ S?
'>
[53y] Nameopt ::=3D Name (S '|' S Name)*
xml allows only
[53] AttlistDecl ::=3D '<!ATTLIST' S Name S AttDef+ S? '>
which forces one, as noted below (i trust the excerpt is, for discussion
purposes, permitted.) to introduce extraenous elements.
when i consider the relative effort of getting a parser to accept a name =
list
and coding applications to treat the interposed elements as transparent, =
i don't
undertstand why this sgml feature was not carried over?
OPTION 1
<!Element MSG_x9999 - - (OV1+)>
<!Element OV1 - - (DE1)>
<!Element DE1 - o EMPTY>
<!Attlist DE1
ID CDATA #IMPLIED
Text CDATA #IMPLIED
System CDATA #IMPLIED
AltID CDATA #IMPLIED
AltText CDATA #IMPLIED
AltSystem CDATA #IMPLIED>
OPTION 2
<!Element MSG_x9999 - - (OV1+)>
<!Element OV1 - - (DE1)>
<!Element DE1 - - (HL7-CE)>
<!Element HL7-CE - o EMPTY>
<!Attlist HL7-CE
ID CDATA #IMPLIED
Text CDATA #IMPLIED
System CDATA #IMPLIED
AltID CDATA #IMPLIED
AltText CDATA #IMPLIED
AltSystem CDATA #IMPLIED>
COMMENTS
=B7 Example DTDs are currently using Option 1.
ISSUES
=B7 Option 1:
=B7 Able to express more Required Value constraints in DTD.
=B7 Easier to parse?
=B7 Option 2:
=B7 Define HL7 V2.3 data types just once, for all message DTDs. May be ea=
sier to
maintain DTDs as data type definitions change.
=B7 Recieving application can determine the data type of previously unkno=
wn data
elements.