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: [no subject]


I used container element <mathML> in the prototype so that when a
specialized topic is generalized the content of <mathML> would
remain intact in the <unknown> element and it would not affect the
validation of the topic since the parser would ignore the content.

The prototype was also implemented as domain so it could easily be
include/exclude in a topic type.

Hope that helps. If anyone has anymore questions, fire away!

Kind regards,
Eric
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
formats.


                                                                           
             Erik Hennum                                                   
             <ehennum@us.ibm.c                                             
             om>                                                        To 
                                       Christopher Wong                    
             04/14/2005 08:21          <cwong@idiominc.com>                
             PM                                                         cc 
                                       DITA TC list                        
                                       <dita@lists.oasis-open.org>         
                                                                   Subject 
                                       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
approach.

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.prefixed "INCLUDE">
<!ENTITY % MATHML.prefix "mml">
<!ENTITY % mathml PUBLIC "-//W3C//DTD MathML 2.0//EN"
"mathml2/mathml2.dtd">
%mathml;

<!-- 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" >
<mml:mrow>
<mml:mo>&sum;</mml:mo>
<mml:mn>4</mml:mn>
<mml:mo>+</mml:mo>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
<mathMLAlternate>4 + x</mathMLAlternate>
</mathML>.
</p>

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
ehennum@us.ibm.com


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]