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: Section 18.334.19 <draw:page draw:name>


Dennis,

Dennis E. Hamilton wrote:
> This editorial correction applies to section 18.334.19 in the latest draft for ODF 1.2 Part I: OpenDocument-v1.2-draft7-13.0dt.
>
> This correction is also applicable to the OASIS Standards for OpenDocument 1.0  and OpenDocument 1.1, at the "Page name" subsection under 9.1.4, Drawing Pages, for both. 
>
>   
Actually not. If we had unlimited time to revisit ODF 1.0 and 1.1 we 
could track changes in ODF 1.2 that could be applied to those versions. 
Unfortunately, I don't have that sort of time so I would prefer to talk 
about corrections to ODF 1.2 going forward.
> Current Text:
> [
> The draw:name attribute specifies a name by which this element can be referenced. It is optional but if present, must be unique within the document instance. If not present, an application may generate a unique name. 
>
> attribute-draw:name_element-draw:page
>
> The draw:name attribute may be used with the following element: <draw:page> 9.2.4.
> ]
>
> Replacement Text:
> [
> The optional draw:name attribute specifies a name by which this element can be referenced.  When present, the attribute value must be unique.  Note that for the <draw:page> element to be referenced from a presentation:pages attribute, the draw:name attribute must be present.
> ]
>
>   
Are you saying that every attribute must have optional or required in 
the prose?
> **NOTE 1: The wording has been restored to align with the ODF 1.0 and ODF 1.1 statements along with replacement of the "generate a unique name" observation with a more-specific note.  This is warranted because the previous statement is found to be misleading in practice.
>
>   
I really don't see the benefit of referencing ODF 1.0 and ODF 1.1 but if 
you insist:

> The draw:name attribute specifies the name of a drawing page. This 
> attribute is optional; if it is used, the name must be unique. If it 
> is not used, the application may generate a unique name.
I think the current replacement text is clearer than "If it is not used, 
the application may generate a unique name."

I am not sure why you added the "referenced from a presentation:pages 
attribute" since that information is already given under the definition 
of presentation:pages, thus:

> The |presentation:pages| attribute specifies a comma separated list of 
> page names as given by |draw:name| attributes on |<draw:page>| 
> elements. The pages are displayed in the order in which they are 
> listed during a presentation that uses this show. Pages can be 
> included more than once.
>
> **NOTE 2: The ODF 1.2 draft adds "must be unique within the document instance."  This is still imprecise.  However, determining the set of values within which a particular draw:name value must be unique is a substantive matter that needs to be addressed separately.
>   
Well, it isn't any less precise than the original and I would argue is 
commonly understood among XML practitioners.

But, you are correct, what does "unique" mean for any attribute value 
that is said to be unique where a document is composed of other 
documents isn't answered by ODF 1.2 nor is it likely to be. Recall that 
we can't be more restrictive or at least that is my understanding, that 
we were previously. Sure, if we were at a major revision/non-backwards 
compatible release, there are a number of things that I would urge 
changing. The "Future Notes" in the current draft reflect some of those 
concerns.

BTW, we should not return to ODF 1.0 or ODF 1.1 to fix this issue.

One of the things, at least to me, that subsequent versions of a 
standard do is to fix known issues with prior versions. In addition to 
hopefully introducing new features with a minimum of new bugs! ;-)

Hope you are having a great day!

Patrick

PS: I think I mention this in a future note but in the next major, 
non-backwards compatible release, I would really like to see a uniform 
method for making references, xml:id comes to mind, along with a uniform 
method for naming (not used for references) so that we could have a 
single mechanism in each case that is uniform across the standard. That 
should simplify implementations as they could share a set of 
expectations for all references and all names. (Names in my opinion 
being useful only for display to the user and so should allow spaces, 
etc. If there are duplicate names for say a style, then we should 
require that they be numbered automatically.) It is true that an 
application could display a name to allow a user to pick a reference but 
the actual underlying mechanism would be an xml:id/xml:idref.

-- 
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]