W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: values of requiredExtensions to use XHTML/MathML (ACTION-2193 ISSUE-2053)

From: Frédéric WANG <fred.wang@free.fr>
Date: Thu, 18 Sep 2008 00:57:03 +0200
Message-ID: <48D18B3F.7040709@free.fr>
To: Doug Schepers <schepers@w3.org>
CC: www-svg@w3.org
Hi, Doug-
> Hi, Fred-
> Coming so close to our Last Call period as your comment was, we went
> ahead and treated it as an LC comment.
> I'm pleased to say that the SVG WG agreed with your comment, and we have
> clarified the wording of the 'requiredExtensions' attribute [1] to say
> generically that the namespace of the language should dictate the value
> of 'requiredExtensions'.
Thanks, It's clearer now.

I have thought about another issue since the last time: it is possible 
that the browser needs several languages to display a foreignObject. For 
instance, attachment xhtml+mathml+svg.xml contains an SVG image with an 
embedded XHTML paragraph, and some MathML formulae in this paragraph. 
Does "a list of required language extensions", means "the list of *all* 
the required languages" ? Or simply of the languages used for the 
children of the foreignObject (here, XHTML). Amaya generates the latter, 
but I don't know what is better for interoperability. For the moment, 
the new wording is good for me.
>   We also added examples to the <foreignObject>
> definition [2] that we hope will help inform authors on how to do this,
> and propagate that way as well.
Yes, it's a nice idea.
Just a small typo: the attribute name is requiredExtensions (with a s ) 
not requiredExtension.
Also, Ishikawa Masayasu proposed a DTD for  XHTML+MathML+SVG ( 
http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ ). It's a working draft but 
it is currently the only rules we have and they are integrated in the 
W3C validator. Hence I think you should try to validate the two last 
examples against this DTD.
> Please let us know promptly whether the new wording satisfies your comment.
> I also have a follow-up question, inline...
> fred.wang@free.fr wrote (on 8/12/08 3:23 AM):
>> In the "Guidelines for Graphics in MathML 2", Michael Kohlhase gives an example
>> where he uses a foreignObject to include mathematical formulae inside SVG
>> graphics, in combination with a <switch/> to provide an alternate text. The
>> requiredExtensions has the value "http://www.w3.org/1998/Math/MathML":
>> http://www.w3.org/Math/Documents/Notes/graphics.xml#mathml-in-svg-guidelines
>> Similarly, when Amaya creates XHTML content in SVG, a
>> requiredExtensions="http://www.w3.org/1999/xhtml" is attached to a
>> <foreignObject/>. The problem is that these two possible values are not clearly
>> indicated in the specifications:
>> http://www.w3.org/TR/SVG11/extend.html#AnExample
>> http://www.w3.org/TR/XHTMLplusMathMLplusSVG/#howto-xhtml
>> As a consequence, this use of <switch> to allow alternate content is quite
>> ironically a problem for interoperability because browsers behave differently:
>> 1) Amaya can display MathML and XHTML inside SVG. It accepts
>> "http://www.w3.org/1998/Math/MathML" and "http://www.w3.org/1999/xhtml" values.
>> 2) Firefox can display MathML and XHTML inside SVG, but since it refuses
>> "http://www.w3.org/1998/Math/MathML" and "http://www.w3.org/1999/xhtml" values,
>> it displays the alternate content.
> Can you point to examples of this working in Firefox?  I'm curious to
> see it.
See attachment testcase.xml. Actually, it's the example I sent to bugzilla:
>> 3) Other browsers that can't render MathML/XHTML in SVG should display the
>> alternate content.
>> Can the SVG WG indicates in the spec that browsers able to display MathML and
>> XHTML inside SVG should recognize the two values
>> "http://www.w3.org/1998/Math/MathML" and "http://www.w3.org/1999/xhtml"?
> [1]
> http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#RequiredExtensionsAttribute
> [2]
> http://dev.w3.org/SVG/profiles/1.2T/publish/extend.html#ForeignObjectExamples
> Regards-
> -Doug, on behalf of the SVG WG

Received on Wednesday, 17 September 2008 22:57:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:15 UTC