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: Draft I-7-13 Review of *:name attributes


Dennis,

I think you fail to appreciate the difficulties with the prior organization.

For example, now it is possible to verify that every element of the 
schema and attribute in fact appears in the current text. (It doesn't 
guarantee any element or attribute is defined correctly but even XSLT 
has its limits. ;-) )

It is also possible to determine when we have been inconsistent with our 
definitions of attributes. Had you read the various definitions of the 
draw:name attribute you would have discovered that not only is that 
attribute different for draw:page but for draw:equation as well. For 
draw:equation, the name cannot contain spaces.

If all the various uses of draw:name had a single definition, then the 
attribute would appear once and only once, as so do many others.

So, by listing the attributes in this manner, it calls attention to 
differing definitions of the same attributes. Perhaps in many cases not 
something we can change in this version but it does make those 
differences apparent.

Moreover, imagine finding that draw:name differs only once for the space 
issue out of 31 separate uses with the old style organization. And 
realizing that it was different from all the other uses. Certainly is 
possible, but not as likely as with the present organization.

As far as "context," I think that is a very dangerous thing to rely on 
in standards. Take the chart attributes for example. Some of them are 
meaningful if and only if they are used with other attributes. But, we 
never said that in ODF 1.0 or ODF 1.1, but relied upon "context." That 
is the sort of "context" that needs to be rooted out of a standard that 
is meant for others to rely upon and not only those who authored it.
So, yes, there is a lot of repetition but that is because one or more of 
the definitions for a particular attribute are different. As definitions 
are reconciled, the amount of repetition can be reduced.

Hope you are having a great day!

Patrick

PS: The excellent cross-referencing and automated checking of the 
elements and attributes are due to Michael's XSLT skills.




Dennis E. Hamilton wrote:
> I notice that there is some sort of regression in the treatment of *:name attributes in the latest draft.  This seems to result from (1) loss of information that is present in the earlier ODF standards for in-context use of *:name attributes and (2) repetitive use of statements that do not apply.  
>
> The only way to clean this up seems to be by comparing the ODF 1.2 passages against the corresponding passages of the earlier specifications and reconciling them.
>
> There is also a problem with what it means to say the value of a *:name attribute must be unique without qualification with respect to the domain of uniqueness.  The xml:id rule (unique with respect to an XML document instance) doesn't work, and I don't think one wants to use the unique domain of the ID type for *:name values in any case, since they are arbitrary strings rather than NCNames.
>
> I am raising this flag because I just noticed how painful it is to figure out what needs to be done to clean up section 18.334 draw:name.  The organization is all right, but useful content has disappeared and what remains appears to be incorrect.  I am concerned that there is substantial regression-curing effort required.
>
> I will start annotating a version of 18.334 in an effort to calibrate the problem.  I will turn something in on Tuesday, my time, so that others can appraise the situation.
>
>  - Dennis
>
> PS: It occurs to me that if one wanted to expedite completion and reviews of ODF 1.2 quickly, the breaking into three parts was a good idea but the entire restructuring of the treatment of attributes has been very costly.  Informative and useful in one way, but very costly in other ways.  (The cross-referencing is great.)
>
> 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
patrick@durusau.net
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]