Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: <firstname.lastname@example.org>, <email@example.com>
- Date: Wed, 17 Mar 1999 10:44:19 -0500
From: firstname.lastname@example.org <email@example.com>
>In the DOM world, default attribute values should show up automatically as
>attributes of the elements they apply to. The Attr.isSpecified() method can be
>used to distinguish between a default and an explicitly entered attribute.
It seems then that isSpecified could be used to filter-out excess attributes
when attempting to recreate a document from a DOM, at least with the above
interpretation. A useful feature that is hard to achieve when you want to
insert SAX filters between a parser and a DOM.
In looking over the Parser/DOM from JavaSoft, it looked like isSpecified is
always true, even for default values.
In looking over the Docuverse DOM, it looked like isSpecified is also always
true, except for updates made by the application, for which it is always false.
We've been playing with an alternate helper class for AttributeList that lets us
set isSpecified, post parse. When you add a filter that is easily configured for
attribute specification (everything you can do in a DTD), things start to get
interesting. The final piece was finding a way to get the docuverse DOM to
accept an attribute at parse time that is not "specified".
Its been an up-hill battle, but we did it without modifying any parsers or DOM
implementations, except for some subclassing of the DOM. Makes us keep
wondering if we have the wrong idea here about isSpecified.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)