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] MathML entities issue in DITA 1.3


Tarun,

As the entities are a matter of convenience to the author, it should be possible to have the FM code (the MathML client in this case, or maybe the DITA FM client) do the translation back and forth, before the XML gets written out to file. It could even be handled in the read-write rules, I guess. I have not looked into this matter in more detail after we discovered this issue but there should be a possibility along those lines.

Kind regards from Amsterdam

Jang

The Content Era, LLC
EMEA Office
Amsterdam - Netherlands
+31 646 854 996
www.thecontentera.com



On 27 May 2015, at 16:28, Eliot Kimber <ekimber@contrext.com> wrote:

> Tarun,
> 
> I think the answer is Story A: DITA does not use entities as a matter of
> policy and therefore any tools you use to create MathML (we do not expect
> normal humans to directly-author MathML markup as it's not actually
> possible in the general case) should not use entities. DITA users are, of
> course, free to configure their local document type shells however they
> choose and can, by that means, turn on the use of entities in MathML for
> DTD-based documents, but the DITA TC does not recommend it.
> 
> It cannot be the case that the use of entities in MathML is any sense
> "standard" since, as an XML specification, MathML could not make the use
> of entities mandatory (because entities can only be used in DTD-based
> documents and DTDs are not mandatory).
> 
> Thus your statement "which otherwise are defined as entities in the
> *standard* MathML markup" [emphasis mine] cannot be true, as the use of
> entities in MathML can at best be a convenience for DTD-based document
> authors. It cannot be "standard" in the sense of "mandatory" or
> "expected". Looking at the MathML 3.0 specification, the RELAX NG grammar
> is now the normative form of the MathML grammar. The 3.0 specification
> discussions the use of entities and emphasizes that they only work when
> the MathML markup is governed by a DOCTYPE declaration and explicitly
> points out that you can't use entities if the XML is not governed by a
> DOCTYPE declaration.
> 
> Any tool that produces MathML markup must already be prepared to do so
> without the use of text entities so I don't see that DITA not using them
> by default presents any practical problem.
> 
> Cheers,
> 
> Eliot
> 
> ----
> Eliot Kimber, Owner
> Contrext, LLC
> http://contrext.com
> 
> 
> 
> 
> On 5/27/15, 6:46 AM, "Tarun Garg" <tarung@adobe.com> wrote:
> 
>> Hi Robert & Eliot,
>> 
>> I was re-thinking this entire e-conversation. Sorry for the (long) pause
>> :).  Last couple of months; it has been really crazy at my end.
>> 
>> I agree to Eliot, that there is no magic to those entities & those
>> characters/codepoints can still be typed/added through numeric
>> representation.
>> 
>> Still, if we go ahead with it in current form (i.e. by default the MathML
>> markup's entities module is excluded in the DITA 1.3 DTDs.), than the
>> question is - How 'MathML support added in DITA 1.3' is being presented
>> to the users ?
>> In my understanding, the story can be any one of the following:
>> - (Story-A) Hence for using the inline MathML, you need to use/type the
>> numeric (or hex) character representation, which otherwise are defined as
>> entities in the standard MathML markup.
>> Or
>> -  (Story-B) Hence the people who want to use inline MathML in their
>> documentation, should include the MathML markup's entities module by
>> enabling the corresponding flag. (But this can cause interoperability
>> issues; would look like 2 different flavors of DITA 1.3 - one with it &
>> one without)
>> Or
>> -  (Story-C) Hence, for using MathML in your documentation; strictly
>> avoid using inline MathML. Store your MathML documents independently of
>> the DITA markup, and reference them with the <mathmlref> element.
>> 
>> Please suggest ?
>> 
>> Regards,
>> Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
>> 
>> -----Original Message-----
>> From: Eliot Kimber [mailto:ekimber@contrext.com]
>> Sent: Monday, March 16, 2015 9:54 PM
>> To: Tarun Garg; Robert D Anderson
>> Cc: dita@lists.oasis-open.org
>> Subject: Re: [dita] MathML entities issue in DITA 1.3
>> 
>> The use of named entities in MathML is simply a convenience and is in no
>> way mandatory--every entity maps to a Unicode character that can be
>> directly typed or represented by a normal numeric character reference.
>> There is no magic to those entities.
>> 
>> Cheers,
>> 
>> E.
>> ‹‹‹‹‹
>> Eliot Kimber, Owner
>> Contrext, LLC
>> http://contrext.com
>> 
>> 
>> 
>> 
>> On 3/16/15, 9:26 AM, "Tarun Garg" <tarung@adobe.com> wrote:
>> 
>>> Hi Robert,
>>> 
>>> Well, if that is the right way to use MathML with DITA, then shouldn¹t
>>> we remove the MathML markup from DITA (effectively removing inline
>>> MathML support). And  provide only <mathmlref>.
>>> 
>>> Regards,
>>> 
>>> Tarun Garg
>>> Computer Scientist, Adobe Systems Inc.
>>> 
>>> 
>>> From: Robert D Anderson [mailto:robander@us.ibm.com]
>>> 
>>> Sent: Thursday, March 12, 2015 6:23 PM
>>> To: Tarun Garg
>>> Cc: dita@lists.oasis-open.org
>>> Subject: Re: [dita] MathML entities issue in DITA 1.3
>>> 
>>> 
>>> 
>>> Hi Tarun,
>>> 
>>> That is intentional. The problem with adding those entities in a DTD is
>>> that they cannot be confined to the MathML markup. So, if we include
>>> them in the Math markup, which is included in DITA, all of those
>>> entities become available in any DITA topic, anywhere.
>>> A lot of my customers noticed that when we tried an early beta of the
>>> math markup, and it didn't go over well (particularly among those who
>>> didn't actually use the Math markup).
>>> 
>>> The best way to get around this is probably to store your MathML
>>> documents independently of the DITA markup, and reference them with the
>>> <mathmlref> element. For example, the DITA markup could be this:
>>> <fig>
>>> <title>My equation will appear here</title> <mathml><mathmlref
>>> href="MathFragment.xml"/></mathml>
>>> </fig>
>>> 
>>> When the math file is stored externally, it can (and should) use the
>>> original MathML DTD, which includes the full range of entities.
>>> Processors should import this math content and treat it as they would
>>> any math markup directly within the topic. Entities will  be understood
>>> based on the definitions in the original DTD.
>>> 
>>> Robert D Anderson
>>> IBM Authoring Tools Development
>>> Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
>>> 
>>> Tarun
>>> Garg ---03/12/2015 06:25:37---I was looking at the MathML DTD fileset
>>> in the DITA 1.3 DTDs. In the file "mathml3-ditadriver.dtd",
>>> 
>>> From: Tarun Garg <tarung@adobe.com>
>>> To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
>>> Date: 03/12/2015 06:25
>>> Subject: [dita] MathML entities issue in DITA 1.3 Sent by:
>>> <dita@lists.oasis-open.org> ________________________________________
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I was looking at the MathML DTD fileset in the DITA 1.3 DTDs. In the
>>> file "mathml3-ditadriver.dtd", the following setting excludes the
>>> MathML
>>> entities:
>>> 
>>> <!-- DITA-specific: Don't allow use of general text entities. DITA
>>> documents should not
>>>   have any general text entity references.
>>> -->
>>> <!ENTITY % mathml-charent.module "IGNORE" >
>>> 
>>> From the comment along with it, this seems to be intentional. But then
>>> how will MathML actually work with DITA 1.3, if these entities cannot
>>> be included in the DITA files ?
>>> 
>>> 
>>> Regards,
>>> Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 



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