Possible extensions to xmlspec DTD

The MathML 2 REC XML sources are (due to historical necessity) written
in xmlspec v1, with some MathML specific extensions.  Eve was developing
xmlspec V2 at the same time, and some of the extensions we needed got
added in V2 (But too late to switch for the MathML REC).
I've been looking what it would take to get the MathML sources to use
xmlspec 2. It would require some name changes in the XML files that
don't really concern this list, but in addition it would be helpful if
xmlspec.dtd could be extended a bit:



** Allowing cross references in label and eg elements


  <!ENTITY % label.pcd.mix
          "#PCDATA|%annot.class;|%termdef.class;|%emph.class;
          |%tech.class;|%loc.class;|%ednote.class;|%ref.class;">
                                                   ^^^^^^^^^^
  <!ENTITY % eg.pcd.mix
          "#PCDATA|%annot.class;|%emph.class;|%loc.class;|var|description|%ref.class;
                                                                          ^^^^^^^^^^^
          |%ednote.class;|constraint">



** Allowing var (or perhaps better %tech.class;) in more places.

  <!ENTITY % eg.pcd.mix
          "#PCDATA|%annot.class;|%emph.class;|%loc.class;|var|description|%ref.class;
                                                          ^^^
          |%ednote.class;|constraint">
  <!ELEMENT sub (#PCDATA|var)*>
  <!ELEMENT sup (#PCDATA|var)*>
                         ^^^




**The MathML DOM appendix (updated XML and generated HTML
     http://www.w3.org/Math/DOM/mathml2/mathml-dom.xml 
     http://www.w3.org/Math/DOM/mathml2/appendixd.html)
  uses an extended version of the attribute  element with new setraises
  and getraises elements

  <!ELEMENT attribute (descr, setraises?, getraises?)>
                              ^^^^^^^^^^^^^^^^^^^^^^
  <!ELEMENT setraises (exception*)>
  <!ELEMENT getraises (exception*)>


  It may be that the "best practice" DOM markup now takes a different
  format in which case we could change (any advice??) otherwise it would
  be helpful if there could be a parameter entity here so that the content
  model could be extended without explictly redeclaring the element.




** MathML has a highly structured appendix with its own specific
   markup. These elements would anyway be in a MathML-specific part
   of the DTD, but the place this specific markup hooks into the main 
   document structure is <MMLdefinition> which has its own definition
   but functions as a <div4> for section numbering, tables of contents 
   etc. In the version of xmlspec v1 that we used for the REC I appear
   to have gone:
   <!ELEMENT div3 (head, (%div.mix;)*, (div4|MMLdefinition)*)>
                                            ^^^^^^^^^^^^^^

  As above I'd rather do this with a parameter entity if possible.
  (In fact adding MMLdefinition to div.mix would work although that's
  rather more general than I'd have liked.)


** variant forms of specref
  specref is defined to be EMPTY and used for internal links.
  Sometimes (especially when there are many links to the same
  thing in close proximity) the mechanically generated text used as the
  link body reads as if it's been mechanically generated....

  We found it necessary to add a variant form that has the same
  hyperlinking semantics but takes non empty content which is used to
  generate the link text.

  There was some discussion on this list ages ago about allowing
  something like this. An alternative to a different element would just
  to open up the content of specref and specify that the application
  should only generate text if the element is empty.
  <!ENTITY % local.ref.class      "|intref">
  <!ELEMENT intref (%p.pcd.mix;)*>
  <!ATTLIST intref
        %common.att;
        %ref-req.att;>



** Inline graphics.
   The MathML spec has lots of inline graphics. These are not well
   supported in the DTD: we used <graphic role="inline"  to get inline
   and appear to have needed an extra attribute:
  <!ATTLIST graphic
        valign         (top|middle
                        |bottom
                        |baseline)      #IMPLIED>
   Having a different element or a specific attribute instread of role="inline" 
   would be good, I think.



David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Received on Monday, 8 July 2002 11:06:44 UTC