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: Custom Slide Shows: presentation:page-ids is unnecessary

This note is in reference to the proposal "Use xml:id in custom slide shows"

It seems to me that this proposal is not needed to solve the identified problem.  

First, the existing presentation:pages attribute is sufficient and, at most, a clarifying remark would be useful in the description of the <draw:page> draw:name attribute. It seems that this part of the problem was related to an implementation defect and not a limitation of the specification.  Switching to draw:id or xml:id does not remedy that.

Secondly, the problem of allowing titles and their accessible descriptions has been resolved for ODF 1.2.  The solution is to use the <svg:title> and <svg:desc> elements under <draw:page>.  This seems to resolve the original problem, since there is no uniqueness requirement for the content of these elements and arbitrary (unformatted) text is allowed.

[Furthermore, the use of xml:id is probably inappropriate as a remedy, introducing more problems than it solves in regard to this specific problem.  I would rather that we deal with xml:id as a separate matter, however.   (There are certainly improvements that would be valuable to make around the use of page:name, draw:id, presentation:name and similar attributes, but that should be addressed at a level beyond the specific problem addressed in this proposal.  I will comment on the laudible metadata use of xml:id when discussing that proposal)

 - Dennis

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 


	1. The Situation
      2. The Problem and Its Resolution
         2.1 Not all presentation pages have page names
         2.2 The simplest resolution that can possibly work
         2.3 Uniqueness of page names is undesirable
         2.4 This problem is already solved
      3. Ways to Tighten the Specification Further in ODF 1.2
      4. History of the Proposal


1.1 OASIS ODF 1.0, IS 26300:2006, and OASIS ODF 1.1 all describe the presentation:pages attribute of the <presentation:show> element the same way:

Section 9.1.4, Drawing Pages, description of Page Name:

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

Section 9.11.6 Show Definitions, description of Pages:

"The attribute presentation:pages contains a comma separated list of page names. 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."

1.2 ODF-v1.2-draft7-12 uses improved text in section 18.613 on presentation:pages:

"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 that the custom is to use space-separate lists in this way, but it is not worth making a breaking change here to switch from comma-separated.]

In ODF 1.2 <presentation:show>, the only element that uses presentation:pages is described as follows:

"The <presentation:show> element specifies the order in which the pages are displayed during a presentation. It can be also used to omit pages from the presentation or to repeat pages during the presentation."

For ODF 1.2 9.2.4 <draw:page>, the draw:name attribute (section 18.334) is specified as follows (section 18.334.19 <draw:page>):

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



2.1 Not all Presentation Pages have Page Names

In ODF 1.0 and ODF 1.1, the only means of identifying <draw:page> elements for reference in a <presentation:show> presentation:list is via the draw:name value on the <draw:page> element.  But <draw:name> is optional.  However, an implementation is allowed to synthesize a unique <draw:name> value if none is present and not provided by other means.

Thorsten Zachmann encountered a situation with an implementation that led to confusing <draw:name> situations when a presentation:list needed to be specified for a <presentation:show> and a page with no <draw:name> needed to be selected.

2.2 The Simplest Resolution that can Possibly Work

There are a number of creative ways to handle this, and changing the specification is not required (nor would it necessarily have prevented the problem).  An editorial remedy is proposed below (section 3).

Note that this same remedy, and the tighter wording of ODF 1.2, are valuable for inclusion as a potential errata item for ODF 1.0 and ODF 1.1.

The bonus is avoidance of any breaking change from ODF 1.0 all the way to ODF 1.2.  The introduction of a previously-unknown attribute is avoided completely.

2.3 Uniqueness of Page Names is Undesirable

The other concern is the desire to use phrases with spaces in the naming of pages and to allow pages to have the same names.  

For all versions of ODF, page:name values must be unique among all <draw:page> elements (at least under the same root element).

(Note that use of an xml:id not only requires uniqueness, but it limits the form of the value to an NCName (no spaces, very few special characters, and only (Unicode) letters and digits except it is not permitted to have any of '0' ... '9' and special characters other than '_' as the first character.)
2.4 This Problem Is Already Solved

In the existing draft of ODF 1.2, there are two new ways to allow arbitrary names to be given to presentation pages: <svg:title> and <svg:desc>, and this arrangement also satisfies accessibility requirements.

There is no relief to this part of the problem for ODF 1.0 and ODF 1.1 (apart from out-of-band implementation approaches that allow for creation of uniqueness internally and for encoding a greater variety of characters).  We should just allow the ODF 1.2 solution to take hold.


3.1 In section 18.334.19 <draw:page> use of draw:name attribute, add the sentence:
"Note that for the <draw:page> to be referenced from a presentation:pages attribute, the draw:name attribute must be present."

(We can leave it to implementations how that is assured if an user hasn't provided the value (yet).)

3.2 Bonus points: Delete the unnecessary source of confusion, "If not present, an application may generate a unique name."  (Applications may do all sorts of wonderful things.  This statement is not needed to enable that and it has apparently provoked poor solutions.)

3.3 In the schema for the draw:name attribute of <draw:page>, the value should probably be of type NCName, not string.  To accomplish this, it is probably best to deprecate string and specify that NCName is recommended whenever a new draw:name is created in an ODF 1.2 document, especially since <svg:title> and <svg:desc> are now available.  (Implementation observation, not for the spec: The same can be done when making a down-level document, but non-NCName strings should be preserved when working with a down-level input that is to stay down-level.) 


This may not be complete.  It is interesting how this one wandered its way around to become the current proposal for ODF 1.2.

2008-12-11: Zachmann affirmation that proposal is for ODF 1.2

2008-12-10: Zachmann request for discussion on 2008-12-15

2008-12-09: Oliver-Rainer Witmann response to Zachmann on the procedure

2008-12-09: Zachmann changes to use xml:id and asks about procedure

2008-12-08: Oliver-Rainer Witmann response to Zachmann on procedure

2008-12-08: Zachmann creates proposal for the problem using draw:id at first

2007-11-22: David Faure confirms understanding of Michael's reply

2007-11-22: Michael Brauer explains extension of the discussion to table:names

2007-11-22: David Faure is confused about discussion not being so much about page names

2007-11-22: Michael Brauer on Drawing page names (re 2006-02-13 minutes)
reports an inconsistency when integrating the proposal into the specification
and apparently this stopped <svg:title> and <svg:desc> getting in right away,
at least for tables.

2007-11-12: Rob Weir draft minutes of 2007-11-12 coordination call, where 
the addition of <svg:title> and <svg:desc> under <draw:page> was approved.

2007-10-26: Malte Timmermann on Accessible Names are usable elsewhere
** This was approved with regard to addition of <svg:title> and <svg:description>

2007-10-26: Michael Brauer on introducing a draw:display-name attribute separate
from the draw:name attribute, and consideration of piggy-backing on xml:id

2007-10-19: Michael Brauer acknowledges reminder from David Faure and concurring
with Christian Lippka's recommendation to deprecate draw:ID and use xml:id since metadata
(RDF) needs it as a fragment ID that is readily identified and also introduced.

2007-10-15 David Faure notes that the problem is still unresolved

2006-02-17: Lars Oppermann reports the analysis in the minutes of 
the 2006-02-13 TC meeting

2006-01-22: David Faure forwards Zachmann note on problems with Drawing Pages

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