Re: Defs and forward references

Russ Shotts wrote:
> The latest spec removes the restriction on forward references and the
> requirement that all referenced elements be defined in a 'defs'.  I will
> admit that I dislike these changes due to the additional complexity they
> introduce.  The spec does not give examples to justify the changes; it
> simply states that the changes were made for compatibility with
> SMIL/Animation.

It seemed that there were already forward references, so the restriction
was felt to be unhelpful.
> I cannot locate details or examples which define the expected behavior.
> Would you please clarify the following:
> 1. Section 6.3.4 states that graphics elements within a 'defs' will not be
> drawn.  While the spec does not state, I would expect some items defined
> outside a 'defs' to not be drawn.  Specifically, it would seem that items
> which are always referenced (e.g., 'linearGradient', a 'pattern', a
> 'symbol', or a 'marker') but are not definied in a 'defs' should not be
> drawn.


> 2. When (or how) are references to be resolved?  When an individual shape is
> read?  Once all shapes are read?

Why would this make a difference?

> 3. What if multiple gradients (or patterns) use the same id? 

Only one element in an XML file can have a particular ID. It is invalid to
have the same id twice.

> 4. What if one of the definitions is before the referencing shape and one is
> after?

There can only be one definition with a given id.

> 5. What if the multiple definitions are spread across this group and its
> ancestors?  And if they are all forward references?
> 6. What happens when a gradient and a shape each use the same id?  Is there
> a single namespace for all ids, or separate namespaces for shapes and fills?

There is a single space for all ids, within which they all have to be
unique within a given xml file.

> The previous version of the spec had a simpler model, yet the Adobe plug-in
> and the IBM viewer had two very different implementations.  If two gradients
> were defined with the same id, the plug-in uses the first definition while
> the viewer uses the most recent.

Both are doing undefined error correction.


Received on Thursday, 6 April 2000 18:12:43 UTC