OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Separation of concerns - Chapter 4


Patrick Durusau <patrick@durusau.net> wrote on 12/08/2009 09:32:09 AM:

> 
> So, if we are going to separate out the concerns of parts 1 and 2 as 
> documents and formulas respectively, may I assume that all the 
> statements in chapter 4 about OpenDocument attribute values and their 
> meanings simply goes away?
> 

1) We should not be referring to office attributes

2) We not be talking about UTF-8 versus UTF-16.  OpenFormula expressions 
are syntactically defined in terms of Unicode strings.  We're in the value 
space of xsd:string, not the XML lexical representation or in the Unicode 
encoded character.  However, at the semantic level, there are a few 
specific functions that do character conversions, like CHAR().  The 
semantics of these functions will need to be defined in terms of character 
representations.

3) There are a few constraints, like : "In OpenDocument, the 
office:value-type of text (string) values is string; if the computed value 
is stored, it is stored in the attribute office:string-value.".  IMHO, 
these should be moved into Part 1, since they are independent of 
OpenFormula.  In particular, if an Extended ODF document uses another 
formula expression language, not OpenFormula, I'd expect that these 
constraints would still hold, since these are really type consistency 
constraints, not statements about Expressions or Evaluators.


> BTW, pseudotypes? (Google "pseudotypes databases" returns 82,800 "hits")
> 
> PostgresSQL uses pseudo-types.
> 
> I really don't think of "database" as a "pseudotype," however it is 
spelled.
> 
> Suggest the easier route is just to define types.
> 

I think of a pseudotype as an alias for another type, used notationally to 
simplify the specification.  They are never necessary to have.  In fact, 
if they were essentially, they would be real types.  But they can be 
useful.  For example, if two types are lexically identical, but one has 
distinct semantics.  But there would be no abuse of logic to call these 
all 'types'. 

-Rob


> (Note to self: insert cross-references where necessary in these 
> definitions.)
> 
> Hope everyone is having a great day!
> 
> Patrick
> 
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]