Re: Attribute types in DOM Level 3

At 9:50 AM -0700 7/29/02, Ray Whitmer wrote:


>I think the general dropping of Abstract Schema will not generally 
>cause a new DTD-specific API to emerge.  At least this is not 
>currently within the work of the DOM WG.

I'm not asking for a full-DTD specific API. I'm asking for a simple 
way to get the attribute type from an Attr object. This is similar in 
scope to the current specified attribute in the Attr interface, or 
the maps of entities and notations in the DocumentType interface. 
These are all information placed in the document model by the DTD 
rather than the instance document.

>On the other hand ID's has been something that the specification has 
>dealt with in the past.  As long as you stick to IDs of the type 
>defined by DTDs, I don't think it is a stretch to say that the same 
>functionality would be expected to work in XML Schema, which has 
>direct support for this type, if you are not distracted by all the 
>additional keys it supports.

This doesn't worry me too much, though I do think that DTDs deserve 
to be preferenced over schemas when they conflict; (e.g. if the DTD 
says an attribute is an ID and the schema says it's a CDATA) then the 
DTD type is reported. For better or worse, DTDs are part of XML 1.0. 
Schemas are not.

>Exposing this by supporting Document.getElementByID has always been 
>optional, allowing for non-validating parsers.

What about attributes declared to have type ID in the internal DTD 
subset? I think all parsers would be required to handle these, 
whether validating or not.

>What if there were a boolean read-only attribute on an attribute 
>node to identify attribute nodes known to be ID's -- would this be 
>enough to be useful?  Obviously on non-validating parsers, the 
>boolean would always be false.  Or would you require something more 
>to solve the problem?
>

It would be useful, but it's not enough. There are nine other 
attribute types (ten if you count "undeclared" as a possibility). 
Some other things we might want:

1. Using IDREF and IDREFS attributes as internal links
2. Determining the notation of an element based on its NOTATION type attribute
3. Using ENTITY or ENTITIES type attributes to load external media.
4. Using the type of an attribute to determine in-memory 
normalization of an attribute value

One type isn't enough. We need all of them.

Finally, I'll note that the Infoset does specify the [attribute type] 
as a characteristic of an attribute information item. If it's a goal 
of DOM3 to fully support all infoset properties, then this one is a 
must, and I think far more important than such weird things as the 
actual encoding.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Received on Tuesday, 30 July 2002 07:53:14 UTC