RE: [dita] object name attribute

["Paul Prescod" <paul.prescod@blastradius.com>]

> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net] 
> Sent: Tuesday, March 28, 2006 11:41 AM
> To: DITA TC
> Subject: [dita] object name attribute
> 
> I was asked during the TC telecon to describe why the name 
> attribute should continue to be supported on the DITA object 
> element.  The object element in DITA is essentially a copy of 
> the object element in XHTML 1.0 Strict.  I understand the 
> idea is to allow the creation of such objects in DITA for 
> passthrough.  The name attribute on an HTML object is how it 
> is addressed in the DOM programming model, for example to 
> identify a component of a form.  Of course, DITA does not 
> directly support HTML forms, but a stylesheet can generate a 
> form from a DITA document and include the DITA object in the 
> form for some purpose. So it is likely that if someone is 
> using object, they may be programming to access its name 
> attribute in the HTML.

I disagree with the statement that it is "likely". I would bet that 99%
of all object tags are used to include flash, SVG and other media
formats, unrelated to a forms. Are there any examples of DITA XSLTs
generating content-embedding forms (as opposed to boilerplate forms) out
there? Do you have examples from the Docbook universe?

I have a hard time envisioning a situation where the XSLT generates a
whole form and the only thing it gets from the input XML is an object
element. No buttons, no input fields, no radio buttons. Just an object.
Everything else is auto-generated.

> The id attribute is another way of addressing a particular 
> object, at least in the W3C DOM, but it cannot always replace 
> the name attribute.  An id attribute must be unique within an 
> HTML document.  The same HTML document could have several 
> form elements, each with their own submit buttons, and each 
> with identical object elements.  All those object elements 
> may need to have the same name attribute because they serve 
> the same purpose in the program.

Let's imagine that someone has a specialization called "SVG Review" that
shows an SVG and generates a form. If the "name" attribute is
predictable, then the XSLT that processes the specialization could add
it. If it is unpredictable, then the ID attribute is probably
appropriate. In addition, the name attribute could be added in the
specialization (using DITA 1.1 features).

> If the intent is to support XHTML objects in DITA, then I 
> believe all the attributes from the XHTML side must be 
> supported in the DITA object.

I think that we should have a clear use-case in mind for every attribute
we use in DITA. If XHTML needs it but DITA does not then we should dump
it. If someone wants to add it in XSLT or specialization then they are
welcome to.

Even in the pure XHTML case, can you give some examples of forms that
embed objects and describe how they are used?

As long as we are going to have this debate, we should amortize our
costs by dumping some other cruft:

 * tabindex - DITA has no notion of tab index. It makes no sense to
manually set the tab index for a single element and leave the rest to
XSLT.

 * usemap - DITA has no notion of image maps. Why should <object> have a
usemap attribute when <image> doesn't.

There are other attributes that are probably quite rarely used even in
the HTML world, but I'll stop my war on cruft with those three.

 Paul Prescod