Print

Print


On Tue, 8 Jun 1999, Richard Light wrote:
 
> First, invent (!) the idea of a "TEI architectural form" which
> application designers can apply to their DTDs.  This simply consists of
> a convention that there is a reserved attribute (say TEIeqv) which
> specifies which TEI element type this element type corresponds to.  This
> can be declared as #FIXED in the DTD, so it never has to be entered in
> actual documents:
>
> <!ATTLIST para
>         TEIeqv CDATA #FIXED "p" >
>
> Second, develop an XSL style sheet which picks up these attribute values
> and renders the elements accordingly.
 
Unless the SGML TEI DTD is to be mapped to more than one XML DTD, or the
target XML DTD is planned to be an ever evolving one (!), I don't
understand what is to be gained by the above. (Then again, I don't think
that I understand architectural forms very well, so therein may lie the
answer).
 
The auditing process that will be required to port the TEI DTD to XML
will require lots of careful human scrutiny. Many choices will have to
made among competing alternatives. I suspect that many of the
transformations will not be readily expressed as simple transformations.
For example, since XML does not allow global inclusions or exclusions,
how are the effected content models to be modified? What is to be done
with those attributes of type NUTOKEN(S) or NAME(S)? All mapped to a new
type, or mapped to a type that makes sense based on the semantics of
their element?
 
- Gregory Murphy <[log in to unmask]>
   __o   Software Engineer
 _`\<,_  Solaris Software
(*)/ (*) Sun Microsystems