[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>∑</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]