MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] object name attribute
Regarding imagemap, DITA does have a domain specialization for such that
sort of begs for incorporation as a core element at some point
(http://docs.oasis-open.org/dita/v1.0/langspec/imagemap.html). Since this
was a more architected approach that tried to lay a real requirement onto
specialization so as to avoid introducing yet more HTML markup into DITA,
the design choices moved some attribute values into element values and did
leave behind some things utterly unused in the use cases we tried to think
up. I don't know whether this experience actually informs on the argument
of cruft, but if it be cruft, it is in a domain that can be elided by the
end user, which cannot be said for core elements.
Use cases? In IBM, we use the object element for Flash movies and such,
but have not yet found a usage instance of the name attribute for
passthrough. We use the imagemap specialization quite a bit. The sample
imagemap described in the article above actually creates a working HTML
imagemap in the Toolkit--just tested it and needed only to rename the
graphic reference from .jpg to .gif for the image that is referenced there.
Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-838-8550
T/L: 678-8550
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
"Paul Prescod"
<paul.prescod@bla
stradius.com> To
"Bob Stayton" <bobs@sagehill.net>,
03/28/2006 02:39 "DITA TC"
PM <dita@lists.oasis-open.org>
cc
Subject
RE: [dita] object name attribute
> -----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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]