W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

[Params] Some comments

From: Cameron McCormack <cam@mcc.id.au>
Date: Sun, 26 Apr 2009 18:38:53 +1000
To: public-svg-wg@w3.org
Message-ID: <20090426083852.GA22541@arc.mcc.id.au>
In the Introduction:

  To address this, this specification also extends the defaultView
  interface to provide a generic and secure means of passing parameters
  into a referenced file.

it’d be more accurate to say:

  To address this, this specification defines an interface to provide a
  generic and secure means of passing parameters into a referenced file.
  This interface is intended to be implemented on all objects that
  implement the Window interface.

In the Requirements section:

  Any valid SVG 1.1 Referenced Parameter Variables must be a valid SVGx
  Referenced Parameter Variables.
  Conformance test suites for other uses of SVGx (e.g. prepress
  guidelines) may be developed. 

I’m not sure what these mean.

  A dynamic SVGx viewer must support the SVGx scripting feature set.

Not sure what this means either, but the wording sounds familiar.  Was
this copied from another spec?

Some of the definitions come from 1.2T, I guess.  Is it best to copy
these over into this spec or just to link to the 1.2T definitions
directly?  Same for the data types.

In the The ‘ref’ element section:

  When acting as a paint server, the child character data content shall
  be treated the value (as text) of the ‘ref’ element; this is unlike
  other paint servers, which provide the value of the paint as an
  attribute value, the ‘ref’ element.

s/treated/treated as/

I don’t really understand the bit after the semicolon.  How do paint
servers provide the value of a paint as an attribute value?

As mentioned briefly on last Wednesday’s telcon, I don’t think it’s a
good idea for the <ref> element to actual change its own child text
content, so that <tref> behaviour can work with parameters without
modification.  I think it would be better to have <tref> referencing a
<ref> element mean that special behaviour is needed (looking up the
parameter instead of looking at the textContent).

I think at the beginning section there should be a definition of what
the value of a <ref> element means.  For example:

  Every <ref> element has an associated /value/, which is determined
  based on the ‘param’ attribute and the set of name/value parameter
  pairs that are available for reference.

so that later on when it says “The value of the ‘ref’ element shall be
derived …” the concept of a <ref> element having a value has been

Is the value of a <ref> element always a string?

  If the parameter information changes, and a the new information does
  not contain a name that was previously matched by the value of the
  ‘param’ attribute, then the existing child character data content
  shall reflect the existing content; it must not change back to the
  original child character data content.

Any reason for this?  I would think it makes more sense for it to revert
to the default that was specified.

  The ‘ref’ element can also act as a mechanism to pass parameters to
  externally referenced resources, in a manner similar to the HTML
  ‘param’ element of the HTML ‘object’ element [HTML4]. In this case,
  the ‘param’ attribute must act as the ‘name’ portion of the name-value
  pair, and the child character data content must act as the ‘value’
  portion of the name-value pair.

How does this work?

   The ‘ref’ element shall be referenced in two ways:
     * as the value in any attribute, as a <FuncIRI>

There are attributes other than xlink:href="" on <tref> where a string
that matches FuncIRI is already a valid attribute value, such as
unicode="" or glyph-name="" on <glyph>, the various value-related
attributes on animation elements, and the RDFa-ish attributes.

An alternative syntax strawman (not to solve the previous paragraph):

    <rect id="button_rect" x="5" y="5" width="100" height="30" rx="15" ry="15" 
      fill="param(color, blue)" stroke="param(outline, navy)" />
    <text id="button_label" x="55" y="30" text-anchor="middle" 
      font-size="25" fill="black" font-family="Verdana">
      <tspan content="param(text-label, 'button')" />

where content="" is a presentation attribute for the CSS ‘content’
property.  An advantage would be that param() could be used in CSS
without the need for an <svg:ref> element, so it could easily be used in
HTML+CSS content.

  If the IRI reference is invalid (for example, it points to an object
  that doesn’t exist or the object is not a valid paint server or it is
  a non-local IRI reference and the viewer does not support it), then
  the fallback value (if specified) is used; otherwise it must be
  treated as if none was specified.

I guess this wording needs to be updated from when only paint servers
were referenceable.

In the DOM interfaces section:

  For parameters that are passed in via the HTML ‘param’ element, the
  user agent must add to this list only values which have the
  ‘valuetype’ of ‘data’. 

I’m intrigued by this valuetype="" attribute. :)  What other types do
you expect to support?  Is valuetype="" on <ref>?

  Objects that implement the defaultView or Window interfaces must also
  implement the WindowParameters interface: 

I think you can just say:

  Objects that implement the Window interface must also implement the
  WindowParameters interface.

I think you need two interfaces: one, WindowParameters, which is
simplemented by all Window objects and would look like this:

  interface WindowParameters {
    readonly Parameters parameters;

and Parameters, as currently in the spec.

  This interface is read-only. Should there be a read-write interface
  available to the referencing document, to allow easy script access to
  parameters, so they can be changes without modifying the URL query
  string or creating ‘param’ elements?

It might be handy, but I don’t think it’s critical.  I guess you would
need to define, for a given embedding context, what parameters get
updated when you change them (e.g. the <param> or the URL parameter).

   Does allowing the author of the referencing document to override
   parameters defined in the URL strings constitute a security or
   propriety risk? What if a site serves a customized resource based on
   a URL string, and that is overridden at the param or script layer, so
   that what is served (think of an ad) is not what what intended by the
   SVG’s content provider. Changing the URL in this case would let the
   content provider know, while changing the ‘param’s or modifying the
   parameters list through script would not. Is this a legitimate

Perhaps then the content shouldn’t be using the <ref> mechanism to allow
the content to be parameterisable.  In HTML, allowing <param> to
override the URL query string parameters in the Parameters object
wouldn’t change what resource is fetched, I imagine.

   Should we expose where the parameter came from, in terms of URL query
   string, ‘param’ element, or other? Should we expose the domain of the
   document where the parameter was set? 

Might be a cross-domain problem.  In a frame, you can’t get
window.parent.document.domain unless it’s same domain.  (Though I
suppose with CORS that could be alleviated.)  What’s the use case for
exposing the domain?  To determine whether to “trust” the parameter or

Consideration will need to be given to how parameter references on
attributes are exposed in the SVG DOM.  For example with:
  <circle r="url(#whatever)"/>

what is circle.baseVal.value and circle.animVal.value?  Do these
parameter references work at the same level as animated values?

That’s all for now.  I don’t think any of these need prevent
publication.  I look forward to the functionality being implemented. :)

Cameron McCormack ≝ http://mcc.id.au/
Received on Sunday, 26 April 2009 08:39:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC