Re: Node interface extension for DOM3

First example:
     <linearGradient id="MyGradient">...</linearGradient>
     <rect style="fill:url(#MyGradient)"/>
The latter is a relative URI which consists only of a fragment identifier.
Checking http://www.ietf.org/rfc/rfc2396.txt,
   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.
So what media type do SVG documents have, and how does that media type
interpret fragment identifiers? If they're IDREFs (which is likely, given
the use of an attribute called "id", but NOT guaranteed -- again, check the
DTD or Schema which defines your language) you can take advantage of the
DOM's support for IDs.  If not, you have to provide whatever lookup
mechanism is appropriate, and/or wait for the DOM or someone else to do so
for you.

Second example:
>  <rect id="MyRect" width="6cm" height="1cm"/>
...
>  <use x="2cm" y="1cm" xlink:href="#MyRect" />

See above comments -- if the id attribute really is declared as an ID, then
the xlink implementation can take advantage of getElementsByID(); if not,
it can't and must implement another solution.

The DOM itself does not provide direct xlink support. I believe the
expectation is that the folks defining XLink will provide an API for that
purpose, possibly by describing how to extend the DOM to support their
spec.

> I want to get all referencers to this object

Reverse mapping from ID to IDREFs is not supported in DOM Level 2. It's an
interesting thought. Will that really be a common enough request to make it
worth building into the DOM, or should it be left as a
middleware/application function?

______________________________________
Joe Kesselman  / IBM Research

Received on Tuesday, 5 September 2000 10:33:51 UTC