[Om3] Complex Variables

[Michael Kohlhase]

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: member-math-request at w3.org [mailto:member-math-request at w3.org]
>>      
> On
>    
>> Behalf Of David Carlisle
>> Sent: Wednesday, July 29, 2009 4:24 AM
>> To: om3 at openmath.org; member-math at w3.org
>> 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
m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase
----------------------------------------------------------------------