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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: DTD invented by Microsoft?!

[ Lists Home | Date Index | Thread Index ]
  • From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 26 Jun 97 10:44:44 BST

Len writes:
>  > Len wrote
>  > >  It is a bad idea and may be the reason SGML community
>  > >  members finally withdraw from XML development.
>  > 
>  Henry S. Thompson wrote:
>  > I'd be interested to hear your reasons for thinking it's a bad idea --
>  
>  Why do we need two ways to do the same thing?  Rick Jeliffe 
>  provided the example in the SGML DTD syntax we know now.  
>  If simplicity is the goal, why introduce this now?

Just because I can express any logical formula using Shaeffer stroke,
or any program in assembler, doesn't mean I should.  Using PEs to
encode an element-type hierarchy not only obscures the author's
intention, it invites accidental error, encourages hacking at the
margins, and makes it harder for non-specialist users to augment the
hierarchy cleanly.  Compare, for example

  <!entity % x.phrase 'myCrystal |'>
  <!element myCrystal (. . .)>

with

  <elementType id='myCrystal' extends='#phrase'>
    . . .
  </elementType>

Understanding why and how the first of these does its work requires
considerable specialist knowledge, and if you don't believe me ask Lou
Burnard and Michael Sperberg-McQueen how easy they have found it to
educate TEI users to make such extensions themselves.

An explicit type hierarchy also simplifies things for the original
author, making the schema easier to maintain, to explain, and to read
for the ordinary user.  Compare:

<!ENTITY % paraContent '(#PCDATA | %m.phrase | %m.inter)*'      >
<!ENTITY % m.phrase '%x.phrase %m.data; . . .'>
<!ENTITY % a.global '        id ID #IMPLIED
                             . . .'>
<!ELEMENT p         - O  (%paraContent;)                    >
<!ATTLIST p              %a.global;
          TEIform            CDATA               'p'            >

with

<!elementType id='p' extends='#global'>
  <mixed>
   <elt href='#phrase'/>
   <elt href='#inter'/>
  </mixed>
  <attribute id='TEIform' presence='fixed' default='p'/>
</elementType>

<elementType id='phrase'>
 . . .
</elementType>

<elementType id='global'>
 <attribute name='id' type='id'>
 . . .
</elementType>

Note finally that the PE method only easily allows a single layer of
specialisation -- once you've defined x.phrase in the above example,
you can't give the results to someone else and say "And to add stuff
to paragraph's content model, define x.phrase to what you want".  If
you want to do that, you have to

<!define % x.phrase '%y.phrase myCrystal |'>

and so on.  The element-type hierarchy approach allows multiple
independent specialisations, with a free choice of attachment points
(i.e. extends='phrase' or extends='myCrystal').

Hope this helps communicate the value I see in this approach.

ht

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (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