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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] OpenDocument 1.2v7-02: Table of Contents


Thanks for the feedback on this and other issues. Some thoughts below:

Dennis E. Hamilton wrote:
> In Document OpenDocument-v1.2-v7-02.odt
> Table of Content and Section-Name Approach (as implemented so far).
> 1. I hate to mention this but the use of the opening tags as the titles of
> sections about the elements having those tags is, well, um, a child that
> only its mother could love?
> 2. It is embarrassing to mention because I fancy using the tag as the name
> of the element in many contexts myself.  But I think the tipoff is that I
> always end up saying "the <foo> element ..." whenever I am talking about the
> element and not a form of its tag.
> 3. I also think this engraves the prefixes of the QNames too much into the
> minds and hearts of the readers.
> 4. And then there's the business of changes to the namespaces and the desire
> to rationalize the spellings and punctuation of XML element names and XML
> attribute names.
> 5. Finally, this is awful when the specification is translated to another
> language.  It would be great if the TOC could be translated too, and use of
> these names won't really permit that. 
Actually #5 doesn't seem like an issue to me. The element names are 
never translated since that is what appears in the schema and in the 
document instance.

It is true I have been involved in discussions in other standards (Bible 
encoding) where providing a schema using locale specific names for 
elements (to enable more accurate hand encoding) that could be 
transformed back into the "standard" schema for interchange was 
discussed. Personally I think it is a good idea because I don't buy the 
argument that element names are merely tokens and don't mean anything, 
therefore let's use meaningful English names. ;-) That is just a little 
too cute for me.

However, and it is a large *however,* note that ODF isn't designed for 
hand encoding and any localization should be a matter of the interface 
that you write for the ODF application. If you are localizing OpenOffice 
or KOffice, etc. your efforts would be focused on the interface, which 
is how the vast majority of users will encounter ODF.

Actually I spoke to an engineer last night at a local club meeting who 
mentioned that he uses OpenOffice and was surprised to learn that XML 
was under the hood.

Now that is what I call effective use of XML as a format. Something that 
has taken a number of years to achieve.
> My sense is that this change in labeling was to provide greater consistency
> and value in locating things, as part of anticipation of going to JTC1 with
> 1.2.  I don't know what to say.
> A. Please give some consideration to coming up with natural-language
> headings that have a systematic relationship to the elements the section
> addresses, when that is the case.  (This could even be more systematic than
> those element and attribute names that have been identified as falling
> outside of the preferred system and might be tidied-up some day.  
I am sure that is what the original draft was intended to do with the 
original names. Unfortunately, and I ran across this attempting to do 
cross-references, there was no way to intuit what section was being 
referenced when you looked at the title in the cross-reference utility.

I am not sure that I could do any better than the original version in 
terms of names that have some "systematic relationship" to the elements. 
Oh, I am sure that the names would appear to me to have such a 
relationship, but that's precisely the problem. Appearing to have that 
relationship to me doesn't help other readers, even if they are also 
native English speakers and is probably positively mis-leading to 
non-native English speakers. At least using the element and attribute 
names there is a one to one correspondence with those portions of the 

Not to mention that literally thousands of cross-references are going to 
be automatically generated once the text settles down a bit and that can 
only happen if we have some means to detect and generate the 

> B. I don't have any good recommendation about the QName prefix that is
> nicely shown in the draft TOC.  Maybe prose instead.  It is nice to have a
> cue about the namespace involved.
Any suggestions on that one anybody? It is possible to include 
preliminary material to some degree in an ISO standard, guide to 
notation, that sort of thing.

Appreciate the feedback!

>  - Dennis
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability 
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

Patrick Durusau
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)

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