RE: SVG 1.2 Working Draft: Comments on 3.2.7 Expression-based attribute values

Hi Kim,

>>>>> "KM" == Kim Marriott <Kim.Marriott@infotech.monash.edu.au> writes:

KM> Basically I just wanted to strongly support the idea of adding
KM> expression-based attribute values. Potentially they are very
KM> useful for widget layout (3.2.3 UI widget support) and for dynamic
KM> layout (3.2.8 Dynamic layout).

KM> I also think it is important to provide as much support for
KM> dynamic layout at the SVG level as possible rather than relying on
KM> XSLT (or declarative variant) or scripting to do this.  First, it
KM> allows for efficient support for animation or user interaction
KM> with the SVG document, say if the browser window is
KM> resized. Support at the SVG level means that XSLT or scripting
KM> need not take place after every user interaction or during
KM> animation.  Second, it simplifies the task of the XSLT or
KM> scripting author, and writing XSLT or scripts is arguably much
KM> more difficult than writing SVG.

    I think we need to look at the problem we are trying to solve.
You mention two above.

  1) A desire to avoid scripting. I view this as not needing a
     'dynamic' viewer.

  2) Simplicity of content. Having the complete definition of the
     element in the element is clearer than having an element and
     having a separate script 'modify' it.

KM> Expression-based attribute values under the name of one-way
KM> constraints provide a simple powerful basis for UI widget layout:
KM> see the explanation of Elliot's RelativeLayout, a Constraint-Based
KM> Layout Manager for Java
KM> http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html

    So I'll say that I've used constraint based layout systems (one of
the Motif widget managers worked this way).  They are powerful, but it
takes some serious thought and often complete reworks of the layout to
get complex examples to work properly.  That said they should probably
be part of any complete 'layout' engine.

   The following is highly edited (he gives very good reasons for all
the requests).

KM> The proposal to add expression-based attribute values potentially
KM> gives the power to program widget layout in SVG and support
KM> dynamic layout. However this depends crucially on the kind of
KM> expressions allowed. [...] 

KM> I think it is important to be able to refer attributes of things
KM> such as text since this allows dynamic layout that adjusts SVG
KM> placement to changes in text size resulting from user preferences
KM> in font or language. I.e. it allows text boxes!

KM> I think it is also important to provide max or min operations [...]

KM> Allowing conditional expressions [...]

KM> A second issue is whether expression-based attribute values are to
KM> be allowed in other attributes apart from path data. [...]

KM> A third issue is checking that an expression has the right
KM> dimension. [...]

KM> A fourth issue is readability: one might want to provide local
KM> variables to allow complex expressions to be broken up and reused.

    So If I read the above correctly, you want the expressions to be
able to access the 'attributes' of all graphical objects, have
conditionals (if/then), functions (min/max), and variables (actually
from your other note it seems you want these 'variables' to act like
user defined functions - the 'defining expression' is re-evaluated
each time).

    At this point you are describing an almost complete scripting
language (the only thing missing is a for loop or a goto - but you
will almost certainly need that for path data) - you just didn't get
to it yet.

    The two changes that I see that are really being proposed here:

    1) You want to enable scripting inside almost all attributes.

    2) Syntax, most of the examples had nice tight syntax for
       referencing other elements, and attributes of those elements

    So #1 is nice until you get to the issue of when/how do you
recalculate the attribute. For these things to make sense a dependency
graph needs to be built and the calculations should be rerun when ever
a dependency changes.  The problem is that with a full programming
language you will generate cycles.  This in turn requires some system
to break cycles - which starts getting really ugly.  

    Even if you only run the script at load time (which is at odds
with your 'window resizing' example at the start) you still have this
issue (and just running them in document order is generally not
sufficient).

     As far as #2 goes my experience with this stuff is that when
people show small examples everything looks _really_ good.  But when
you go to build the BNF for the expression syntax you very quickly
realize the examples are impossible to express in BNF and you need to
start adding lots of syntactic sugar to disambiguate which quickly
makes the examples just as unreadable as the original.

     Also I would be hesitant to invent a 'new' scripting language
when Dynamic viewers are already required to support ECMAScript
(JavaScript) .  it would be ideal if most of these things could be
buried in global functions or something - or a mapping could be
defined to ECMA.

KM> My final issue: What will be the effect of transformations on
KM> these external parameters? I feel that when accessed from a SVG
KM> element within a transformation that the appropriate
KM> transformation needs to be applied to the external parameter
KM> value.

    What is the transformation on a stroke-width?  Depending on the
transformation you will get a different answer if you treat it as
horizontal length vs a vertical length.

    I am writing this note not to say that 'expressions' in attribute
values is a bad idea, but to try and bring this discussion back to
reality a bit.  The dependency issue is very problematic, and the
syntax issue is also critical.

    Also I wanted to make it clear that this is _still_ scripting -
perhaps simplified, moved around and more convenient but it is
scripting - and hence it is unlikely that static viewers would render
it (unless lots of the proposed features were simplified/dropped so a
static renderer could easily evaluate them 'on the fly').

Received on Tuesday, 13 May 2003 09:01:07 UTC