[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]