RE: [1.2T LC]: accessing rules for traitAccess

Dear Erik and all,

Thanks for your answers. I agree that my examples with the begin raise the question "when is the begin evaluated". Actually this was ways beyond the scope of my question, and honestly I don't know. And I don't think there is a simple answer to that question. So the simpliest would be to disallow such modification of the IDs.

If I focus on the case of the href, (modifiying the href using setTrait or modifying IDs of the element the href refere to, like for my begin example), I understand that according to the current spec the following happen:
if I do 
<script>
anim = document.getElementById("anim");
anim.setTrait("href, "id2 ");
</script>
this throw an exception, but I I do
<script>
v1 = document.getElementById("id1");
v2 = document.getElementById("id2");
v1.id='id2';
v2.id='id1';
</script>
This throw nothing, but also has no effect (Correct?)

So my recommended option would be that:
- The attribute xml:id cannot be modified once the element has been inserted in the tree. (so modifying the xml:id of an element in the tree should raise a NOT_SUPPORTED_ERR)

This way the same behavior would be observed in both cases. Anyhow, IMHO I don't see any legitimate reason for modifying IDs of element already in the tree.

That would be option 4 in your question.

Julien


-----Original Message-----
From: Erik Dahlström [mailto:ed@opera.com] 
Sent: mercredi 8 octobre 2008 16:29
To: Julien Reichel; www-svg@w3.org
Subject: Re: [1.2T LC]: accessing rules for traitAccess

On Tue, 07 Oct 2008 14:24:05 +0200, Julien Reichel <Julien.Reichel@spinetix.com> wrote:

> Hi,
>
>
>>> Thus it is possible to modify the target of an animation by switching
>>> the xml:id of two elements (which is equivalent to a change of the href
>>> in the animation). So IMO this restriction  is insufficient to enable
>>> simplification of the UA design.  Note that modifying the xml:id of
>>> other even in the tree can also be used to modify the behavior of other
>>> attribute (like a begin="id1.begin" for instance)
>
>>Well, the begin time would be resolved previously right?
>
>>If the id 'id1' was missing at first, the begin time would be resolved as
>> 'indefinite' (according to SMIL animation), and when the 'id1' was added
>> to the document that still wouldn't cause a re-evaluation of the begin
>> time (or at least I didn't find a reference that said one must do that
>> in such a scenario).
>
> I was thinking about an example more like this one:
> <svg>
> <video xml:id='id1' begin='10' ...>
> <video xml:id='id2' begin='5' ...>
> <g>
> <animate xml:id='anim' begin='id1.begin' ... >
> </g>
> <script>
> v1 = document.getElementById("id1");
> v2 = document.getElementById("id2");
> v1.id='id2';
> v2.id='id1';
> </script>

Your question boils down to: when is the 'begin' attribute evaluated? My guess is that neither SVG nor SMIL will give a satisfying answer at this time, but what I think should happen is that 'begin' should be evaluated in conjunction with starting the document timeline, which would be dependent on the 'timelineBegin' attribute.

Once the 'begin' time has been resolved I think it shouldn't change, so that if the 'anim' element had started and the 'id1' and 'id2' id:s were exchanged, the begin time would not be re-resolved. I think SMIL says that already.

It might be possible to see the above example as a case where the tree is being built, in which case it might be allowed to modify the animation elements. It's a maybe though.

> this script will have the same effect as this one (not allowed)
>
> <script>
> anim = document.getElementById("anim");
> anim.setTrait("begin', "id2.begin");
> </script>

Currently this would give you the well-defined behaviour of not modifying the 'begin' attribute, and to throw an exception.

If setTrait was changed to not throw in these cases, and the 'anim' element had a resolved begin time already, would you expect setTrait to affect the animation? How?

> I don't know if that causes a problem, but IMO changing the ID let you modify pretty anything when using SMIL. (note that my example might be too simple, and full of errors to trigger the problems I was pointing out, but should explain the principle... hopefully)

It's always good to illustrate the problem :)

> My main point was:
> - there are some restriction concerning setTrait and SMIL, which will complicate the design of the script to handle those element, however those restriction are not sufficient for the implementer of UA to really be able to take advantage of them (IMHO). So removing those newly added restriction (they were not present in the previous version), actually simplify the content creation without additional implementation burden on the UA architects.

Ok, would any of the following options satisfy you?

a) don't throw exception, do attribute modification, but disallow the modification from having an effect (similar to how setAttributeNS is defined to work)
b) don't throw exception, don't do attribite modification at all (silently ignore error)
c) don't throw exception, do attribute modification, allow modification to have an effect (and if so, what effect?)
d) something else (additional details you can provide here much appreciated)

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Friday, 10 October 2008 07:51:27 UTC