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
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
