Re: [office-comment] Comments on ODF 1.0 Errata 01 Committee Draft 02

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Makoto,

On 08/20/08 15:19, MURATA Makoto (FAMILY Given) wrote:
> Michael,
> 
>> First of all, the paragraph you are referring to here is not subject of 
>> the errata. The errata corrects the last paragraph of section 17.5 only.
> 
> Agreed as far as my first point is concerned.  I will send another
> e-mail about this to this ML, incorporate it in the second defect 
> report from Japan, and wait for two months.
> 
> However, I would argue that my other points are very relevant to the
> subject of this technical corrigenda.
> 
> First, the correction to 17.5 appears to try to address #70 in the
> Japanese defect report.

Yes, this is correct.
> 
>> 70.  The last para of 17.5
>>
>>    All other kinds of IRI references, namely the ones that start with a
>>    protocol (like http:), an authority (i.e., //) or an absolute-path 
>>    (i.e., /) do not need any special processing. This especially means that
>>    absolute-paths do not reference files inside the package, but within
>>    the hierarchy the package is contained in, for instance the file system.
>>    IRI references inside a package may leave the package, but once they
>>    have left the package, they never can return into the package or
>>    another one.
>>
>> First, an absolute IRI reference begins with a scheme (rather than protocol), 
>> and it does not start with an authority or an absolute-path.  
> 
> This point has not been addressed, since the corrected wording still
> allows IRI references to start with an absolute-path.  I believe that

I'm not sure if I do understand this. The term "relative-path" is 
defined by RFC 3986 in section 4.2 as follows: "A relative reference 
that does  not begin with a slash character is termed a relative-path 
reference." It is a certain type of a relative reference. There are 
other types of relative references that are not relative paths. These 
are listed in the above paragraph in addition to absolute references.

This means, section 17.5 does not differ between relative references and 
absolute references, but between relative paths, and other types of IRIs.

What is a little bit unfortunate is the reference to RFC3987 in the 
previous paragraph. In ODF 1.0 we have referenced RFC 2396, which is a 
predecessor of RFC3986, but changed this to a reference to RFC3987 when 
we were asked to clarify that ODF supports IRIs.

> best way to address it is to rely on RFCs 3986 and 3987 wihout trying to 
> normatively summarize what is specified there.  Less is more.  Therefore,
> I would argue that my second and third points are very relevant to #70 in N0942.
> 
> Second, the correction to 15.31.4 appears to  try to address #79 in the
> Japanese defect report.

That is correct.
> 
>> 79.  Attribute names in 15.31.4 "Tick Marks" 
>>
>> Two attributes (chart:axis-interval-major and
>> chart:axis-interval-minor) appear in the body text, while four
>> different attributes, (chart:tick-marks-major-inner,
>> chart:tick-marks-major-outer, chart:tick-marks-minor-inner, and
>> chart:tick-marks-minor-outer) appear in the schema.
> 
> This original comment did question the  attribute name "chart:axis-interval-major".
> I am merely reforumating my original comment, which has not been 
> addressed yet.

Well, this is probably one interpretation of the comment. But I have to 
admit that I have understood the comment as a hint that the attributes 
mentioned in the description do not match those define in the schema 
below the description, since it does not say that the attributes are not 
defined at all.

Again, thank you for your feedback. I believe we will discuss it in one 
of the next TC calls.

Best regards

Michael
> 
> Cheers,
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering