OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Message Length vs Processing Speed

[ 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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS