OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: Re: [dita] object name attribute

Hi Paul,
Well, I don't have a use case for the name attribute.  I wasn't 
around when the object element was added to DITA, so I guess I'm 
not clear on what purpose it serves.  I presumed that since it 
was such a good match for the HTML object element that it was 
intended to support the production of such elements in HTML 

It did seem a bit unusual to have such an HTML-centric element in 
a markup language intended for multiple output formats.  Perhaps 
someone with more history could explain the rationale for object. 
Is it there just to support Flash in the output?  Are there any 
processing expectations for object when it is output to PDF and 
other non-HTML formats?  Is it expected to be filtered out when 
generating non-HTML output?

Bob Stayton
Sagehill Enterprises
DocBook Consulting

----- Original Message ----- 
From: "Paul Prescod" <paul.prescod@blastradius.com>
To: "Bob Stayton" <bobs@sagehill.net>; "DITA TC" 
Sent: Tuesday, March 28, 2006 12:39 PM
Subject: RE: [dita] object name attribute

> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net]
> Sent: Tuesday, March 28, 2006 11:41 AM
> 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 
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 
element. No buttons, no input fields, no radio buttons. Just an 
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 
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 
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 
embed objects and describe how they are used?

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

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

 * 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

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