[param] Re: Fwd: XSL-FO SG comments on SVG Referenced Parameter Variables 1.0

Hi, Liam-

Thanks for the feedback.  Replies inline...


Doug Schepers wrote (on 6/14/09 12:49 AM):
>
> The XSL-FO (sub-)group looked at
> the primer, http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090430/
> document, http://www.w3.org/TR/SVGParam/
>
> Comments... since this is an early draft, it'll be fine if you
> take these comments into account, but a formal reply is not
> necessary.
>
> Not clear exactly which values can be overridden by params. E.g.
> what about SMIL animation atribute values?

Yes, we need to define this more clearly.  We are inclined to allow any 
attribute to take a param() as an attribute value, or as part of an 
attribute value.


> We definitely prefer param(qname) to the use of a URI for
> the parameters -- e.g. if you can put a URL for a value you
> should be able to put any URI, but not clear how this works
> for different media types.

Yes, the SVG WG has settled on 'param()' for a number of reasons 
(including simplicity), and will be publishing an updated draft this 
week which reflects that.


> We'd like to see more on exactly how the parameters can be
> supplied, e.g. when SVG is embedded in XSL-FO or XHTML.

The Param spec deliberately avoids making any normative requirements on 
any other spec... that's up to that spec to define.  But the Param spec 
does discuss how parameters might be passed in from X/HTML, based on 
existing elements in X/HTML (the <param> element).

 From XSL-FO, I'm assuming you would pass in parameters from XSL-FO like 
this:
   <xsl:param name="color">#6495ED</xsl:param>

That seems fundamentally the same as X/HTML <param>, and it should work 
just fine with the Parameters interface, and I'd be happy to include 
such informative wording, and include an example in the Primer.  If 
there's something else I should know about it, please do educate me.


> Parameters should (like XSLT parameters) allow the default to
> be expressed in element content, so that you can have markup,
> e.g. "logo" might by default be a g element with a circle and
> a square in it...

If I understand you, you're asking to be able to pass in markup as 
element content?  That seems to complicate matters too much; this is 
intended to be a very simple, lightweight, and predictable bit of 
functionality, easy to author by hand or by an authoring tool.  I should 
include wording that clarifies what happens if someone passes in text 
content that is either markup or script... I don't want to get into the 
whole document.write() problem.

If you wanted to "pass in" a logo or other graphic to a template SVG, 
you could supply the graphic in an external file ("resources.svg") and 
pass in the URL as the parameter for a prepared <use> element, like this:

<xsl:param name="logo">path_to/resources.svg#logo-id</xsl:param>
...
<use xlink:href="param(logo)"/>

Anything more complicated that than, you can always use XSLT to 
transform the SVG file itself.


> Can param() be combined in expressions with other values?

We plan to allow that, yes.  In particular, we are looking at the calc() 
value from CSS3.


> Can they be referenced from param detaults?

I'm not sure what you mean here (even modulo the typo).


> The primer describes URL parameters, e.g.
> color=cornflowerblue&text-label=fnord
> but needs (1) to allow ; as a CGI separator, and (2) to
> be defined also in the spec itself, not just the primer.

No, the spec deliberately avoids making any restrictions on how other 
specs choose to pass in parameters; it only says what to do when 
parameters are received.  Anyway, I believe the syntax for URL query 
strings is already defined by RFC1738.


> For XSL-FO, we may want (or need) a more general way of overriding
> things even where the SVG instance doesn't provide for it.
> Example: "use _this_ font for text"

This is out of scope for the Param spec, which only describes a simple 
mechanism for authors to define how specific parts of their reusable SVG 
content can be changed.

If you need more than this, I think that should be defined in XSL-FO, 
perhaps by using XSLT to preprocess the SVG file to insert the desired 
param functions?


> There was also a suggestion to associate types with parameters,
> to avoid run-time errors, much like XSLT 2.0's "as" attribute.

Sorry, you went right over my head with this one...


> Overall we think it's a good idea, and may also be helpful to
> XSL-FO users.
>
> I hope this helps.

Thanks!  It does help.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 14 June 2009 06:28:59 UTC