Message Length vs Processing Speed

[james anderson]

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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)