Re: Defs and forward references

Russ,

At 03:44 PM 3/14/00 -0600, 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.
>
>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.

That is correct. It sounds like the spec would be more clear if this were
stated explicitly. I have made myself a note.

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

At rendering time, in effect. Remember, there is a DOM and the document can
change. You can't assume that the document will stay the same as when it
was parsed.

All references right now go through the ID mechanism. In a valid XML
document only one element can have a given ID. Here is a snippet from the
XML 1.0 spec:

Validity Constraint: ID
          Values of type ID must match the Name production. A name must not
appear more than once in an XML document as a value of this type; i.e., ID
values must uniquely identify the elements which bear them. 

>
>3. What if multiple gradients (or patterns) use the same id?  The spec does
>not indicate whether the reference resolves to the first definition, the
>most recent, or the last.  

The document will not pass validity checking, then. The viewer should stop
processing the document once it encounters the second ID with the same
value and notify the user in order to conform to error processing rules
defined in the spec.

>
>4. What if one of the definitions is before the referencing shape and one is
>after?
>
>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?
>
>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 viewers have not gotten around to implementing error handling
correctly, it appears.

>
>Things get far more complex with the above changes.  For example, consider
>the following case:
>
>
><g>
>  <ellipse style="fill:url(#id01)" cx="100" cy="50" rx="75" ry="20" />
>
>  <linearGradient id="id01".../>
>    <stop offset="0%" style="stop-color:red"/>
>    <stop offset="100%" style="stop-color:blue" />
>  </linearGradient>
>
>  <circle style="fill:url(#id01)" cx="100" cy="175" r="75" />
>
>  <linearGradient id="id01".../>
>    <stop offset="0%" style="stop-color:blue"/>
>    <stop offset="100%" style="stop-color:green" />
>  </linearGradient>
>
>  <rect style="fill:url(#id01)" x="20" y="300" width="400" height="50" />
>
>  <linearGradient id="id01".../>
>    <stop offset="0%" style="stop-color:green"/>
>    <stop offset="100%" style="stop-color:red" />
>  </linearGradient>
>
>  <polygon style="fill:url(#id01)" points="0,500,200,500,100,400" />
>
>  <linearGradient id="id01".../>
>    <stop offset="0%" style="stop-color:black"/>
>    <stop offset="100%" style="stop-color:blue" />
>  </linearGradient>
>
></g>
>
>What gradient is used for each shape?

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

Received on Friday, 17 March 2000 17:03:50 UTC