On 29.07.2009 18:14 Uhr, Robert Miner wrote: > On the issue of having the cd/name attributes, my understanding was this > pair comprised an "annotation key" that specified the role of the > annotation. I think Michael's point was he wanted something more > specific for the role other than "alternative representation" which is > the default when the annotation key attributes aren't there. He was > suggesting introducing a new sub role called "complex variable". That is exactly what I meant, thanks for translating.
Michael > > > I want to carefully re-read ch5 before committing myself. We should all > try to look at Ch 5 before the call tomorrow. > > --Robert > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> > On > >> Behalf Of David Carlisle >> Sent: Wednesday, July 29, 2009 4:24 AM >> To: [email protected]; [email protected] >> Subject: Re: Complex Variables >> >> >> 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. >> >> > _______________________________________________________________________ > >> _ >> > > > -- ---------------------------------------------------------------------- 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
