OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only

  • 1.  Re: FW: [office] Discussion Requested - Version Identification at theFeature Level

    Posted 10-14-2008 07:01 
    On 10/13/08 20:38, robert_weir@us.ibm.com wrote:
> I agree that this would be useful to have.   I wonder if we could do 
> something like what we have in Appendix D 'Core Feature Sets' ?  In other 

Sounds like a good idea. This information would be informative. For this 
reason, I would prefer a solution that keeps the information separate 
from the normative text.

> words, list all of the section/subsection numbers along with what version 
> ODF introduced or substantially changed that feature.

Some time ago I have developed an XSLT style sheet that lists the 
elements, attributes and attribute values of an ODF schema in a 
spreadsheet[1].

One could apply this style sheet to the ODF 1.1 schema and the ODF 1.2 
schema. The result would be one sheet that summarized the elements and 
attributes of ODF 1.1, and another one that summarizes those of ODF 1.2. 
I'm not a spreadsheet expert, but believe it should be possible to 
compare these two so that one gets a table which for each element and 
attributes states whether the element or attribute is new, or whether 
its value changed. Since the table representation of spreadsheet and 
text document does not differ, one could simply copy the spreadsheet 
data into the ODF specification itself as an appendix.

Well, it should also be possible to do the comparison by XSLT itself, 
but I don't have something for this at the moment.

One does not get all changes we made to ODF 1.2 this way, but I believe 
most of them. In any case, using this as a start seems to be much easier 
than collecting the information manually.

> 
> The assumption is that new features are introduced into new subsections. 
> This may be a bad assumption.

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.

Michael

> 
> -Rob
> 
> "Dennis E. Hamilton"


  • 2.  RE: FW: [office] Homonymy Impact - Version Identification at the Feature Level

    Posted 10-14-2008 21:53 
    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.  

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.

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: FW: [office] Homonymy Impact - Version Identification at theFeature Level

    Posted 10-17-2008 07:24 
    Dennis,

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


  • 4.  RE: FW: [office] Homonymy Impact

    Posted 10-17-2008 17:05 
    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


  • 5.  RE: FW: [office] Tools for Tracking - Version Identification at the Feature Level

    Posted 10-14-2008 21:53 
    I agree that using tools with respect to schema changes would be great for
making sure that those levels of changes and introduction of new elements
and attributes and attribute values (and defaults) are caught.

I am also concerned with semantic changes that are not caught this way, and
for that we need to deal with the text too.  

More to think about.  Thanks.  I do think that the use of mechanical aids
would be invaluable.  My thoughts turn to generating the spec (or such parts
of it) from a database, rather than mining the spec, but I am a little
afraid to follow that thinking very far.

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content