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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Support for foreign content vocabularies such as MathML and SVG

Hi Chris,

I guess my last email never made it through to the list in its entirety.
Erik pretty much nailed the issues regarding the integration of mathML in
DITA.  Here is mathML schema version:

Kind regards,

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
elementFormDefault="qualified" attributeFormDefault="unqualified"

 <xs:import namespace="http://www.w3.org/1998/Math/MathML";
schemaLocation="mathml2.xsd"  />

 <xs:element name="mathML" type="mathML.class" />
 <xs:complexType name="mathML.class">
      <xs:element ref="mml:math" />
  <xs:attribute name="class" type="xs:string" default="+ topic/unknown
math-d/mathML " />

  <xs:group name="math-d-unknown">
      <xs:element ref="mathML" />

Eric A. Sirois
Staff Software Developer
DB2 Universal Database - DBA XML Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue Pages (Internal)

"Transparency and accessibility requirements dictate that public
information and government
transactions avoid depending on technologies that imply or impose a
specific product or
platform on businesses or citizens" - EU on XML-based office document

             Erik Hennum                                                   
             om>                                                        To 
                                       Christopher Wong                    
             04/14/2005 08:21          <cwong@idiominc.com>                
             PM                                                         cc 
                                       DITA TC list                        
                                       Re: [dita] Support for foreign      
                                       content vocabularies such as MathML 
                                       and SVG                             

Hi, Chris:

I haven't provided much detail. Let me try to rectify that and to encourage
Eric Sirois to expand on it as needed -- Eric pioneered and prototyped this

In a DTD definition, the <unknown> element would have an ANY content model.
So, a specialization of <unknown> could contain unknown markup such as the
elements from the MathML vocabulary. A Math domain module that specializes
<unknown> would also include the MathML DTD:

<!-- declaration for the specialized wrapper and alternate element -->
<!ENTITY % mathML "mathML">

<!ENTITY % mathMLAlternate "mathMLAlternate">

<!-- included MathML document type -->
<!ENTITY % MATHML.prefix "mml">
<!ENTITY % mathml PUBLIC "-//W3C//DTD MathML 2.0//EN"

<!-- definition for the specialized wrapper and alternate element -->
<!ELEMENT mathML ((%math.qname;), (%mathMLAlternate;))>
<!ATTLIST mathML %global-atts;
class CDATA "+ topic/unknown math-d/mathML ">

<!ELEMENT mathMLAlternate (%ph.cnt;)*>
<!ATTLIST mathMLAlternate %global-atts;
class CDATA "+ topic/section math-d/mathMLAlternate ">

In passing, for semantic clarity, we may want to define an
<unknownAlternate> element with the same content model as <section> to
serve as the base for the alternate content.

Anyway, you could then create document instances like the following:

<p>... as in the formula <mathML>
<mml:math display="block" >
<mathMLAlternate>4 + x</mathMLAlternate>

An editor that recognizes both the DITA class attribute and the MathML
vocabulary should be able to provide MathML editing within the <unknown>
specialization -- for instance, using an equation editor for that content.

DITA adopters who didn't need equation editing wouldn't need to include the
MathML domain in their document types.

Hoping that's useful,

Erik Hennum

Christopher Wong <cwong@idiominc.com> wrote on 04/14/2005 01:18:40 PM:

> Erik Hennum wrote:
> > Finally, I agree that the <unknown> element doesn't address the
> > attribute extension problem -- an important and difficult problem. The
> > <data> element provides some relief there, though maybe not a complete
> > solution. Anyway, <unknown> would give us the ability to incorporate
> > standard existing vocaublaries for special content -- something that
> > we need, too.
> >
> I don't think I completely understand your <unknown> proposal. Can its
> content have elements that are NOT specialized from DITA? That is, can
> they have new attributes not defined in DITA? If the answer is no, then
> its utility is doubtful: you cannot include content from arbitrary
> models if their attributes are ruled out. If the answer is yes, then we
> have validation issues. If <unknown> simply means "here be dragons, do
> not parse, do not enter" to a DITA processor, that may not be an issue.
> But if you also want to process the <section> elements in <unknown>,
> then how can that be validated? Remember that many of us still author in
> DTD-based or even barely-XML (FrameMaker) editors.
> Chris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]