RE: FW: [office] Homonymy Impact

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

Patrick,  

I am completely aligned with your thinking about ways to sort out homonymy
and that it has to work within the structure of ODF 1.2, with any improved
reconciliation as a future possibility.

I think there is more to be said for sections such as 18.1029 table:name and
other attributes that have values to be understood in different domains
depending on the element where the attribute appears.  One also needs to
sort out when attributes having different names are expressing values in the
same table:name domains, etc.  I expect the achievement for 1.2 would be to
show care in the prose and not attempt to introduce some explicit model for
all of this.

With regard to databases, it may be that a database might be most useful in
keeping track of all of the dependencies in ODF even if not used directly
for authoring.  I think I need something like that simply to sort out ODF
for myself [;<).  I suppose it would be an interesting real-world exercise
of an ODF .odb document.

 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
http://lists.oasis-open.org/archives/office/200810/msg00090.html
Sent: Thursday, October 16, 2008 21:55
To: dennis.hamilton@acm.org
Cc: office@lists.oasis-open.org; Michael.Brauer@Sun.COM;
robert_weir@us.ibm.com
Subject: Re: FW: [office] Homonymy Impact - Version Identification at the
Feature Level

[ ... ]
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 
homonyms.
[ ... ]
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) 
thus:


******

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

...

18.1029.13

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

[ ... ]