Michael, > Problem1: I remember that David and I talked about just making the first > form part of strict content MathML, and I had thought that we decided to > do that for convenience,
Srict content mathml doesn't allow element content of ci. I suspect you were thinking about allowing the type attribute in strict > Problem 2: 5.3.2 says that " The value of the |encoding| attribute may > contain a media type that identifies the data format > for the encoding data." > So it should really be > <annotation-xml encoding="|application/mathml-presentation+xml|"> No, the sentence after the one you quote explictly says to use MathML Presentation For example, Section 6.2.3 Names of MathML Encodings identifies the strings MathML, MathML Presentation, and MathML Content as predefined values for the encoding attribute that may be used to identify MathML markup actually the sentence in (5.2.3.2 Attributes) does need to be adjusted a bit now that there is a proposal to have a mime type for presentation mathml, to make it clear that the existing usage of using the name MathML Presentation takes precedence. > Problem 3: the <annotation-xml> element in the example does not have @cd > and @name attributes. But I think we really should have them. Otherwise > they default to alternative-representation from the mathmlkeys CD. But > this seems to be too weak to key the intended behavior of a presentation > engine, namely to use the pMahtML directly. I don't understand this comment. The default presentation of an objected annotated with "presentation mathml" is that presentation. I don't see how a cd attribute would effect the default presentaion at all (although of course a particular renderer may be affected by any markup changes), Perhaps it should have a cd otherwise I assume mathmlkes:alternate-representation will get used, but this doesn't seem too bad actually, and in any case, doesn't affect the presentation. 4.2.8.3 When a Presentation MathML annotation is provided, a MathML renderer may optionally use this information to render the MathML construct. This would typically be the case when the first child is a MathML content construct and the annotation is provided to give a preferred rendering differing from the default for the content elements. > But do we really want to have the enclosing math tag around the > <msup>? All examples in MathML2 didn't have enclosing math (or enclosing OMOBJ) when mathml or openmath is used as annotations. I think that's the correct convention. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________ _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
