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

on 13/5/03 10:58 PM, Thomas E Deweese at thomas.deweese@kodak.com wrote:

> 
> 
> 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.

Actually I don't think I want loops, goto or recursion, I think thatıs when
you move into a real programming language. What I want is just enough to
provide the sort of layout adjustment that is required to handle changes in
text size or browser window size or simple widget layout when you have a
fixed number of SVG elements.

I agree this could be done with scripting, but that is not to say it *is*
scripting--just that scripting is a way of implementing these features.
However the advantages of extending SVG rather than just requiring scripting
are:
* It makes SVG documents with this capability easier to understand, author
and interchange. The problem is that otherwise two languages need to be used
with opaque dependencies between them and scripting languages are
non-declarative and non-XML compliant.
* An SVG browser can provide a more efficient implementation to handle
dynamic evaluation and incremental update in linear time.
* Dynamic evaluation is less expensive to support than general purpose
scripting, thus making it more suitable for less powerful computing
devices. In particular I think it would be feasible to at least partially
provide expression based attribute evaluation as say part of SVG Tiny or SVG
Basic.
* If parameters are to be added to use and symbol (SVG 1.2 Working Draft
3.2.4) then I think you must provide at least some form of dynamic attribute
evaluation in SVG to allow these parameters to be used. It would seem
strange if you were always required to write scripts for this.

And I have a philosophical argument: If these features are needed in many
SVG documents then SVG itself should provide them. It's for similar reasons
that SVG provides basic animation: this could be done with scripting for
instance but it is considered important and useful enough to include as part
of SVG. This is in accord with the desire expressed in the SVG 1.2 Working
Draft (3.4 Possible Approaches point 5) that "It would also be good if a
large percentage of common use cases could be achieved without having to
resort to scripting."

> 
>   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).
> 

That is why I am not allowing cycles. I think you can do most of what you
want, certainly the sort of stuff Allen Razdow wants with layout adjusting
to text size, without cycles. This means you can use standard one-way
constraint solving techniques which have been used for decades in GUIs and
spreadsheets. These are really fast and pretty simple to implement. Again I
refer you to the excellent paper by Brad Vander Zanden et al,
 Lessons learned about one-way, dataflow constraints in the Garnet and
 Amulet graphical toolkits, ACM Transactions on Programming Languages and
 Systems (TOPLAS)}, 2001, pages 776--796,
  http://doi.acm.org/10.1145/506315.506318.

>    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.

I wasnıt really suggesting a syntax here, my example was based on the
example from the SVG 1.2 Working Draft. Previously we have suggested a
variety of syntaxes, e.g. use of XPath to access attributes. However, at
this stage I think we need to decide what capabilities we would like and can
implement and then worry about the syntax.
> 
> 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.

Good point. As a first cut maybe this shouldn't happen automatically but
instead allow the SVG programmer to explicitly apply the current
transformation or its inverse to a point.

Cheers

Kim
-- 
Kim Marriott
School of Computer Science & Software Engineering
Monash University, Wellington Rd, Clayton, Vic 3800, Australia
Ph: ++61 (3) 9905-5525, Fax: ++61 (3) 9905-5146
Email: Kim.Marriott@infotech.monash.edu.au

Received on Wednesday, 14 May 2003 00:39:49 UTC