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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: FW: [office] Homonymy Impact - Version Identification at theFeature Level


Dennis E. Hamilton wrote:
> Michael,  
> I love the built-in cross-referencing that appears in the new drafts for ODF
> 1.2.  That is a tremendous feature.
> It brings up a new problem, because not all uses of the same attribute name
> are the same and there is only one entry in section 18 for all of the
> homonyms.  
Yes, well, the gathering of all the attributes with the same name 
together was in part to illuminate the homonym problem, it isn't a 
solution to it.

Further, I think it should be clear that we cannot fix the homonym 
problem in the 1.2 release so we are relegated to distinguishing the 
> This suggests to me that we need some structure below the attribute name
> entry in order to sort out the homonymic cases.  
> I also assume that the cross-reference mechanism will not be able to handle
> that, because there is no way to indicate to it which homonym is intended
> where.
> The situation I am referring to is what Patrick discusses in his annotation
> of the section on the table:name attribute.  This applies in many other
> places (text:name and style:name probably) and for other attributes.
> See the draft7-10 text for section 18.1029 table:name for an illustration of
> the need to provide specification by homonymic case, and how Patrick has
> been handling it.  It seems to me that this treatment of version-specific
> introduction and change might have to be at the level which is now reflected
> by bullet-list items.
Using 18.1029 as an illustration, I think we would have to go to third 
level divisions, (my comments that would not appear are in parentheses) 


18.1029 table:name

18.1029.1 General

The table:name attribute has different definitions depending upon the 
element on which it appears.

(This general section is always needed when sections follow so that it 
is possible to distinguish between citing the section and all of its 
subsections versus simply citing a short bit of prose that appears after 
the main section number. If you notice any place where I have not done 
this, please comment.)

18.1029.2| <table:cell-range-source>|

In the <table:cell-range-source> element, the table:name attribute 
specifies the name of the source database range or named range.

(I am concerned about this use of an element name will be confused with 
top level element names that are used to generate the other linking. It 
can be distinguished as it does appear in the attributes chapter but 
that does mean an exception has to be written for it and for any search 
engine. The problem is that I don't know of another principled basis on 
which to distinguish the uses of the attribute.)



(And, to be consistent, each attribute definition needs to have a 
cross-reference only to the element for which it is valid.)


That is just a rough idea and I would have to do it is full on a couple 
of the more complicated ones to see if it would work across the board.

I would note that in the long run, whatever solution we adopt here, 
should be constructed with a view of sorting all these uses out for a 
more systematic solution in ODF 2.0.

BTW, without a separate reply I have mis-givings about your notion of 
generating text from a database. I have seen examples of database 
composition of documents and they read like database composition of 
documents. Database composition encourages a style of writing that is 
joyless to read and write.

Hope you are having a great day!


>  - Dennis
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> http://lists.oasis-open.org/archives/office/200810/msg00051.html
> Sent: Tuesday, October 14, 2008 00:04
> To: robert_weir@us.ibm.com
> Cc: office@lists.oasis-open.org
> Subject: Re: FW: [office] Discussion Requested - Version Identification at
> the Feature Level
> [ ... ]
> Thanks to the changes that Patrick made, this assumption is actually 
> correct. Each element is described in a subsection of its own, and the 
> same applies to attributes. With the generation of the element and 
> attribute lists I have further introduces a simple pattern for reference 
> marks. This makes it easy to add reference to the subsection where an 
> element or attribute is defined.
> [ ... ]
> ---------------------------------------------------------------------
> 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 

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]