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: [office] Generalizing svg:title and svg:desc for titling andaccessibility


a more general use of title and description elements is an interesting 
idea, and something that we may want to research for the next (post 1.2) 
version of ODF.

Two things that we should consider in addition to your items below are:

1. ODF applications typically don't operate on a DOM model. In 
particular, they don't expose all XML elements to the user and they 
don't provide a user interface for all elements. Furthermore, a lot of 
ODF elements have the purpose to structure information internally in a 
file, but are not intended to be displayed or otherwise made available 
to the user.

This means that there are a lot of elements where having a title and a 
description is reasonable, but there are also a lot of elements there 
this is not reasonable.

An example may be the <office:styles> element that is just a container 
for styles. Or the <text:drop-cap> element that holds drop cap 
definitions within a style.

2. ODF adopts elements and concepts from other standards, where this is 
possible. This is one of the design principles defined in the ODF TCS's 
charter. Graphical objects for instance have been adopted from SVG. 
That's the reason why <svg:desc> and <svg:title> are used. One may 
replace these with more general elements, but this would mean that we 
move away from SVG here, or from other standards for other elements. 
Please note that I don't want to argue here that using more general 
elements here is not possible at all. I only want to point out that this 
also has impacts that we must consider.

Best regards


On 12/15/08 05:42, Dennis E. Hamilton wrote:
> Michael,
> In researching Thorsten Zachmann's original problem, I noticed that svg:title and svg:desc already solve a part of the specific problem that Thorsten had identified some time ago. 
> I also noticed that there was some hesitance around using the svg:title and svg:desc with anything but graphical objects, and that OpenDocument-v1.2-draft7-12.odt only has those elements associated with graphical objects (specifically, the dr3d: and draw: QNames).
> It occured to me that there may be a simpler solution that deals with accessibility requirements more broadly (other than the grouping concerns that Richard Schwerdtfeger has noted).  I was not around when this was looked into and I apologize if I am revisiting questions that were already explored and ruled out.  I thought it worth checking out.
> Here is a simple sketch of what I suggest be explored:
> 1. Derive two attributes from Dublin Core that can be understood as the title of the object an element represents and the accessibility-appropriate description for that object.  (Note, these are attributes, rather than elements, making it easier to have them be optionally ubiquitous on elements throughout the ODF schemas.) 
> 2. Because of specialization, these should probably be named something like office:title and office:desc, even if inherited from an appropriate Dublin Core element or attribute.
> 3. In the ODF Schema, make these two attributes optional on all elements under an ODF document root or otherwise.
> 4. The intention is to allow these attributes to be used on any element that corresponds to a document entity that has a distinct, perceivable object in presentation of the ODF document.  Depending on the situation, an user agent may provide this information when the object is to be referred to, and as alternative information to whatever the rendition of the object is.  It depends on user agents how such information is captured for particular elements and how it is used in assisting users for accessibility and other reasons.  Rather than attempt to foresee the specific elements for which that is involved, it seemed useful to allow implementations to work it out, depending on the functions that they support and the perceptual model for what users can describe for consultation by others.  The idea is to be tolerant of their optional occurrence everywhere..
>  - Dennis
> I don't have answers about these, but they might bear exploration if the basic idea seems worth pursuing.
> 5. It strikes me that such attributes may also be of interest as subjects of the RDF metadata via URI references to their elements, although in this case, it might be more useful to use elements rather than attributes.  In writing this, I've become rather fond of the attribute approach, since it is harder to declare an element that can be a sub-element of any other element but itself.  This does make it more difficult to have internal markup (and attributes on internal elements) though.
> 6. If an option element were used, it might be useful have an office:title attribute required, the office:desc be an optional attribute, with no content in the element itself.  That might avoid any trickiness with the texts being presented under foreign-element content-processing conditions.  The other value of an element is the availability of its identification with an xml:id and crisper interpretation if identified in an RDF subject/object URI.  There are other variations on this idea that might be considered in satisfying the intended use cases.
> 7. I have not addressed whether and how the office:title and office:desc can be propagated into elements under other schemas that are appealed to by reference (math, svg, etc.).  That's not a new problem though.
> 8. I have not addressed whether and how office:title and office:desc might appear comingled where <svg:title> and <svg:desc> are already supported.  I see that <svg:title> and <svg:desc> are appropriated from the SVG specification in ODF 1.1, as well as ODF 1.2.  The svg:title and svg:desc elements were not incorporated for ODF 1.0 even though that specification makes use-by-reference from the same SVG 1.1 specification.  The ODF 1.1 and proposed 1.2 definitions seem to contradict or pre-empt what SVG 1.1 section 5.4 provides for those elements, which have attributes and can have internal markup.  I don't know if one would want to deprecate the svg:title and svg:desc, from ODF 1.1, or simply let it stand.  
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> http://lists.oasis-open.org/archives/office/200812/msg00102.html
> Sent: Thursday, December 11, 2008 23:23
> To: ODF TC List
> Cc: 'Thorsten Zachmann'; 'David Faure'
> Subject: [office] Custom Slide Shows: presentation:page-ids is unnecessary
> [ ... ]
> 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.
> [ ... ]
> 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.
> [ ... ]
> 2007-11-22: Michael Brauer explains extension of the discussion to table:names
> http://lists.oasis-open.org/archives/office/200711/msg00036.html
> 2007-11-22: David Faure is confused about discussion not being so much about page names
> http://lists.oasis-open.org/archives/office/200711/msg00034.html
> 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.
> http://lists.oasis-open.org/archives/office/200711/msg00035.html
> 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.
> http://lists.oasis-open.org/archives/office/200711/msg00023.html
> 2007-10-26: Malte Timmermann on Accessible Names are usable elsewhere
> http://lists.oasis-open.org/archives/office/200710/msg00065.html
> ** 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
> http://lists.oasis-open.org/archives/office/200710/msg00064.html
> 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.
> http://lists.oasis-open.org/archives/office/200710/msg00042.html
> [ ... ]
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

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