RE: [office] ODF 1.2 draft 7 - table chapter

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Michael, I tend to agree with your rationale, although I think something
more definitive (and normative) needs to be considered when the
specification calls forth some capability that must be reconciled with an
externally-defined characteristic, especially where adopters would be
surprised by inconsistency in an interchange situation.  The resolution
should be pragmatic and specific to the case at hand, I suppose.

For example, it is simple to say how different forms of calendar date are
identified in the markup and what their displayable forms look like. When
conversion between such dates and when manipulation of such dates is
involved, I think it may require something more specific.  If we say that
conversion and manipulation are expected, we may need to identify how that
is to be done.  We don't specify operations on text that require knowing
anything about the language code, as far as I know, so we are more-easily
excused, although if we did string-based comparisons that assume
language-sensitive collation (maybe in the database), that is a different
story.  We also don't claim (as far as I know) any dependence on the amazing
amount of guidance around Unicode in language-specific use and how it is to
be rendered in the presentation of a document. 

It occurs to me that, for example, there may not be a good specification for
how one expresses the difference between two Gregorian dates (internally
represented) as a time interval with units larger than days.  (What does it
mean to be 2 months apart, or 3 years and 3 months apart, etc.)  To the
degree that we have stakeholders who would expect to see the same answer
across implementations, we may have to choose an authority and identify that
we are assuming that.  We could also say that we are not doing so and that
is intentional.  Either one strikes me as a responsible thing to do when
there is not a settled and easily-known way of doing it.  (I would be happy
to learn that ISO 8601 settles the matter.  I may have overlooked it.  I
also haven't checked to see if the XSD data type definitions provide any
relief.  It would be awkward to have to say the expected result is what is
produced by product X version Y on platform Z.) 

I think I have wandered too far off the point about reviewing the feedback
on the Table Chapter and I will now get back to business ...

 - Dennis

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 

Sent: Friday, October 31, 2008 01:30
To: robert_weir@us.ibm.com
Cc: office@lists.oasis-open.org
Subject: Re: [office] ODF 1.2 draft 7 - table chapter

On 10/31/08 03:22, robert_weir@us.ibm.com wrote:
http://lists.oasis-open.org/archives/office/200810/msg00173.html
> I could see burning a lot of digital ink on trying to solve this problem. 
> But we might consider when this is something akin to trying to define 
> "bold" in text, or defining what the "red" value in an RGB triplet means, 
> or defining a language code.  We're allowed to specify a language code of 
> "de_ch", but we are not obliged to define and explain what exactly 
> comprises the Swiss Germany dialect.
> 

That's a very interesting observation. On the hand I understand that is 
is useful to have normative references for the calendars used. But on 
the other hand, we use language codes (which are defined by an ISO 
standard), but they don't tell us anything how to implement them, nor 
what is correct. So, if we have for instance "de-DE", then this does not 
tell us what words a spell checker has to be consider to be correct, or 
what a grammar checkers needs to check. Well, both does not have an 
influence of the formatting of a document, but hyphenation is also 
controlled by language tags, and this has an influence on the formatting.

In addition, we had a so called "Rechtschreibreform" in Germany two or 
three years ago, where the spelling of many words has been changed. The 
language code does not tell you whether the old or the new spelling of a 
word is correct. This is also not considered to be an issue.

So, given that, I start to believe that some information what the 
calendar values are may be useful, but that normative references are not 
required.

[ ... ]