Re: Exploring new vocabularies for HTML

On Mar 30, 2008, at 05:07, Bruce Miller wrote:
> I think there's some confusion here --- tho' it may be mine.
> I personally think the most compelling case for annotations,
> especially in a web context, is to provide presentation MathML
> for display to humans, along with the corresponding content
> MathML (when available) for export to applications (or perhaps
> for audio rendering, or ...).  For any non-trivial math, for
> software to infer the meaning from the presentation is really
> just a wild guess; humans do somewhat better.  Perhaps the
> notion of a "semantic web" has lost its popularity, but this
> use case seems to be exactly what a semantic, and accessible,
> web needs.
>
> I do somewhat share the concerns about using annotations to embed  
> other
> applications' internal forms, leading to bypassing the MathML
> entirely, and increasing chances of the forms getting out of sync.

So shouldn't Content MathML be developed to be rich enough to  
encompass the semantics products need to round-trip but in a vendor- 
neutral way?

> But even so, _if_ there is the means for a browser to skip over a
> content mathml annotation, that mechanism could as easily skip
> other annotations as well --- provided it can find the end of
> the annotation, which of course is not necessarily trivial
> once you're outside of the XML world.

Implementing skipping is not the problem. The problem is that *some*  
products might not skip the annotation thereby getting different data.  
That can be bad because the different data is out of sync or because  
the different data is better and everyone else is missing out on the  
better data.

>> After discussing this with Hixie on IRC and testing a bit with  
>> Gecko, I'd like revise my position. Since SVG in MathML works fine  
>> in the #1 SVG-in-MathML browser engine implementation (Gecko in  
>> Firefox 3), I think requiring the <semantics><annotation-xml  
>> encoding="SVG1.1"> cruft around <svg> is just silly and it would be  
>> better to make <svg> subtrees conforming directly inside  
>> Presentation MathML.
>
> I'm not sure I'm catching the relevance of SVG here...
> I could see an argument for allowing SVG inside presentation
> MathML with the sense of "This is just a token that looks _this_ way",
> though it would probably be best if it were wrapped in an
> mo, mi, mtext, or whatever.
> There are some worries about exporting such expressions to
> a MathML application.

If the MathML application doesn't support SVG, I don't see how the  
<semantics><annotation-xml encoding="SVG1.1"> cruft helps anything  
when there are no other annotation branches.

> Further, I would also agree that specifying an annotation as SVG
> seems somewhat silly, since it's presumably just providing another
> way to present something that is already sufficiently described.


The use case involves showing things that have no Presentation MathML- 
native markup:
http://golem.ph.utexas.edu/~distler/blog/archives/001475.html

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 30 March 2008 08:29:29 UTC