On 29.07.2009 11:24 Uhr, David Carlisle wrote: > 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 >
that is a remnant of the time we did not have media types for the three flavors of MathML. Otherwise it becomes contradictory with the sentence > 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." One of them has to be changes. Michael > 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. > ________________________________________________________________________ > > -- ---------------------------------------------------------------------- Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 Professor of Computer Science Campus Ring 1, Jacobs University Bremen D-28759 Bremen, Germany tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase [email protected] http://kwarc.info/kohlhase ---------------------------------------------------------------------- _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
