[
Lists Home |
Date Index |
Thread Index
]
- From: james anderson <mecom-gmbh@mixx.de>
- To: "Dolin,Robert H" <Robert.H.Dolin@kp.ORG>
- Date: Tue, 16 Dec 1997 20:09:14 +0100
i'm not sure whether it falls within the lists scope to pose questions of the
sort "what's the rational for this ?", but i hope so. i'm not sure where else
would be more appropriate and as someone implementing a parser, when i discover
stipulations which are non-intuitive i'm at least curious about the rational for
some of the stipulated "conforming parser" behaviour and welcome the opportunity
to at least ask why things are the way they are.
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 definitions
should be repeated as necessary or should be attached to an intermediate "type"
element.
where sgml permitted something like
[53x] AttlistDecl ::= '<!ATTLIST' S (Name | '(' Nameopt ')' ) S AttDef+ S?
'>
[53y] Nameopt ::= Name (S '|' S Name)*
xml allows only
[53] AttlistDecl ::= '<!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
· Example DTDs are currently using Option 1.
ISSUES
· Option 1:
· Able to express more Required Value constraints in DTD.
· Easier to parse?
· Option 2:
· Define HL7 V2.3 data types just once, for all message DTDs. May be easier to
maintain DTDs as data type definitions change.
· Recieving application can determine the data type of previously unknown data
elements.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|