[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Message Length vs Processing Speed
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|