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

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

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

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

    But this is clearly not sufficient for 'the real world', the first
'complex' example is table layout, where very often the number of
rows/columns is unknown ahead of time - even if it is known would you really
suggest replicating the layout code for each row?  

    What about iterating overt text content (you said you wanted
access to bounds of substrings of text).  I'm convince that you must
have iteration.  

    Additionally you say you don't want to support recursion but once
you admit the utility of user defined 'functions' you really need to
support recursion.

KM> I agree this could be done with scripting, but that is not to say
KM> it *is* scripting--just that scripting is a way of implementing
KM> these features.  

    I guess I don't know what definition of scripting you are using,
in my book you really have to call the ability to say "10+40" is
scripting - I'll admit very simple scripting - what you are describing
requires an implementation to have a very complete scripting engine
(symbol tables, functions with arguments and return values,
conditional logic, and you asked for a type of strong typing) I would
draw the line between complex and simple scripting at functions and
conditionals - simple is unbranched single flow.

KM> However the advantages of extending SVG rather than just requiring
KM> scripting are: 

KM> * It makes SVG documents with this capability easier to
KM> understand, author and interchange. The problem is that otherwise
KM> two languages need to be used with opaque dependencies between
KM> them and scripting languages are non-declarative and non-XML
KM> compliant.

    Your new language has almost all the same properties - There are
still two languages, it isn't XML the attributes (even with schema)
will have to allow any content, and I at least don't consider anything
with an 'if' statement declarative.

    I will agree that by placing the script in the attributes you make
the dependencies clearer.

KM> * An SVG browser can provide a more efficient implementation to
KM> handle dynamic evaluation and incremental update in linear time.

    Linear in terms of what? The number of expressions evaluated?  I
mean the fact that because you have disallowed cycles means that only
a single pass through the dependency tree is needed is nice, but I
still think that saying cycles are illegal when they are so very easy to
create is a _huge_ problem (IMHO a fatal one).

KM> * Dynamic evaluation is less expensive to support than general
KM> purpose scripting, thus making it more suitable for less powerful
KM> computing devices. In particular I think it would be feasible to
KM> at least partially provide expression based attribute evaluation
KM> as say part of SVG Tiny or SVG Basic.  

    This depends greatly on the complexity of the language.  In Batik
for example it was relatively simple for us to support ECMA Script
because we could use existing software (which additionally compiles
the ECMAScript to Java bytecode, which in turn is general compiled to
machine code - meaning very high performance for complex scripts).

    For a new language we would have to write our own parser, runtime,
etc which would require lots of time and effort as well as most likely
not being as good.

KM> * If parameters are to be added to use and symbol (SVG 1.2 Working
KM> Draft 3.2.4) then I think you must provide at least some form of
KM> dynamic attribute evaluation in SVG to allow these parameters to
KM> be used. It would seem strange if you were always required to
KM> write scripts for this.

    The mechanism for this is as yet undefined, it is most likely to
use either ECMAScript or XPath - both existing standards.

KM> And I have a philosophical argument: If these features are needed
KM> in many SVG documents then SVG itself should provide them. 

    It does. This is why (unlike HTML) SVG _REQUIRES_ dynamic viewers
to support ECMASCript.  The fact that we didn't have to include the
100 odd pages of the core ECMAScript specification in the SVG
specification is a feature not a flaw.

    The real question here (in my mind) is should such a document be
considered a static document.  I am not so sure.

KM> It's for similar reasons that SVG provides basic animation: this
KM> could be done with scripting for instance but it is considered
KM> important and useful enough to include as part of SVG. This is in
KM> accord with the desire expressed in the SVG 1.2 Working Draft (3.4
KM> Possible Approaches point 5) that "It would also be good if a
KM> large percentage of common use cases could be achieved without
KM> 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).

KM> That is why I am not allowing cycles. I think you can do most of
KM> what you want, certainly the sort of stuff Allen Razdow wants with
KM> layout adjusting to text size, without cycles. 

    Akk! :) This makes for a _really_ hard to use system. One of the
things you stated was that this would help 'creative' people Designers
vs coders.  I know quite a few creative people very few of them are
prepared to construct data flow diagrams to ensure that cycles are
not created.  I agree that this is the 'pure' solution, but for the
general public this is an almost impossible system to use.

    This is made especially problematic because SVG already has
implicit one-way dependencies worked into it (percentages and CSS units
like em's are good examples).  This means that it would be fairly easy
for people to create cycles that are almost invisible.  Finally I've
never seen a system that made it really easy to understand where the
cycle is coming from.

KM> This means you can use standard one-way constraint solving
KM> techniques which have been used for decades in GUIs and
KM> spreadsheets. These are really fast and pretty simple to
KM> implement. 

    The actual constraints are still expressed in a 'scripting
language'.

    But I think we can now separate the two.  So you suggest that
attributes be allowed to have some sort of script that defines the
values.  And those scripts can not be allowed to generate cycles.

    Could this system be implemented (perhaps not as efficiently) by
having the implementation register a mutation event listener on every
element that is referenced from the piece of script and having the
mutation event trigger the script again.

    In particular this would move the dependency tracking to elements
not to attributes (or computed values).  So for example you couldn't
have the width of a rectangle depend on a piece of text, but the
position of the same text depend on the location of the rectangle.

    In theory it might be possible to know that changing the location
of the text doesn't change it's width (and hence the rectangle) but in
the real world this would be almost impossible to track correctly.

KM> Again I refer you to the excellent paper by Brad Vander Zanden et
KM> al, Lessons learned about one-way, dataflow constraints in the
KM> Garnet and Amulet graphical toolkits, ACM Transactions on
KM> Programming Languages and Systems (TOPLAS)}, 2001, pages 776--796,
KM> http://doi.acm.org/10.1145/506315.506318.

    I would but I don't feel like subscribing (also I've used the
Amulet toolkit briefly in the past so I'm generally aware of the
concepts here).  My experience with one-way constraints (mostly for
Motif) is that they are very difficult to get right, you almost never
get them right the first time, and when they go wrong the errors are
very difficult to track down.

Received on Wednesday, 14 May 2003 08:37:04 UTC