SVG param(eters)

Hello Doug, hello www-svg,

about the param discussion here:
http://lists.w3.org/Archives/Public/public-html/2009Nov/0665.html

why not to extend or to add a new functionality with the syntax
of SVG views like this:
some.svg#svgView(transform(scale(2)))

Parameters are somehow related to an alternative view of
the document, therefore this fits more or less.
The main advantage it, that this method does not depend
on the history or fate of other formats like (X)HTML, only on 
something, that already exists in SVG.

http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
http://www.w3.org/TR/SVGMobile12/linking.html#SVGFragmentIdentifiers

Either one could use a new keyword:
some.svg#svgView(param(name(value)))

or a new related construction:
some.svg#svgParam(name(value);name2(value2))
or
some.svg#svgParam(id1.attributeName(attributeValue);id2.attributeName2
(attributeValue2))
with id1/id2 fragment identifiers within the document
the parameter is related to, similar to addressing
event-values in animations.
(this needs some more considerations about masking critical characters)

To insert some content in title, desc or text elements, but avoiding larger
backwards incompatibilities, one could add an additional method to create 
an entity (in doubt overwriting entities defined within the 
document-type-declaration as fallback, except the entities already defined 
by XML of course):
some.svg#svgEntity(entityName(entityValue);entityName2(entityValue2))

Maybe one has to combine all these to be able to use all of these at once:
some.svg#svgView(transform(transformType(transformValue));param(id.attributeName(attributeValue));entity(name(entityValue));etc)

I would prefer the last method, if mixing parameters
with GET-parameters in the query in not accepted
(what would have of course the advantage, that a script on 
the server could know too, what happens in the generated 
content).


Olaf

Received on Monday, 30 November 2009 11:03:07 UTC