Re: Request For Feedback: Traits

Hi Doug.

(Only following up to www-svg.)

Doug Schepers:
> The SVG WG feels that this interface addresses many author-requested needs,
> including the ability to access and set the animated or computed value of an
> attribute, and to access individual components of microsyntaces such as the
> numbers in rgb(0,0,0) and the path segments in a 'path' element's 'd'
> attribute [3].

 From my reading there is no way to set the animated value of an
attribute with the TraitAccess interface, since there are no
setXXXPresentationTrait methods.

> It also provides strong typing, which is useful even in
> weakly-typed languages like EcmaScript since it can distinguish between
> booleans, strings, and numbers (a useful feature for those who script SVG,
> since DOM methods only return strings), and provides clear exception
> messages for erroneous trait values, allowing for ease in debugging. The SVG
> WG does not feel that it is a redundant feature to DOM 3, but is rather
> complementary. 

I think it is useful, since I see many scripts (including some of my
own, when I can't be bothered) that do something like:

  var x = Number(rect.getAttributeNS(null, "x"));

ignoring the fact that units may have been used.

One problem with the typing though is that I'm not sure how an IDL
sequence<octect> (used by ConnectionEvent.receivedData, Connection.send,
SVGGlobal.binaryToString and SVGGlobal.stringToBinary) maps to an
ECMAScript type.

> Any criticism (or praise) of the 'traits' feature is very welcome. We are
> especially interested in whether you see value in providing this mechanism
> beyond the scope of Java, such as in EcmaScript, C#, or other languages. If
> there are particular features that you feel are inappropriate or that
> conflict with other specifications (such as DOM 3), and which would prevent
> your adoption of 'traits', we encourage descriptions of those issues along
> with proposed resolutions.

Others have commented on the incompatabilities between uDOM and DOM 3
and I agree that these should be resolved.

A few conflicts between uDOM and DOM 3:

  - raising an exception when adding a capturing event listener with
    EventTarget.addEventListener
      => the exception should only be thrown if the implementation
         does not also support DOM 3
  - raising an exception when passing Node.appendChild a Node that is
    not an Element
      => the exception should only be thrown if the implementation
         does not also support DOM 3
  - Element.getAttributeNS taking an IRI, while DOM 3 Node namespaces
    are URIs
      => all mentions of IRIs wrt objects that could also implement DOM
         3 should be URIs

Maciej has mentioned a much more exhaustive list.  These conflicts would
be a sizeable stumbling block for implementing a viewer that supports
both uDOM and DOM 3.  The features of uDOM should be a compatible subset
of DOM 3.

Here are a number of other issues I picked up after just reading through
that page this afternoon (some may have been raised already, for which I
apologise):

  A.2.4 Element Addition

    This section talks about Nodes when it seems to be restricting
    itself just to Elements.  It should however allow Nodes in the case
    that DOM 3 is also implemented.

  A.2.7 Attribute/Property Normalization

    The normalization methods should be made explicit, I think, rather
    than leaving it up to the reader to infer from the examples.

  A.3.2 Node

    "Setting textContent on an element that do not support"
                                            ^^
  A.3.3 Element

    In the prose for setAttributeNS:

      A uDOM implementation must support setAttributeNS for all
      attributes.

    yet in the Exceptions section:

      NOT_SUPPORTED_ERR: Raised if setAttributeNS tries to set an
      unsupported attribute.

    which would seem to be never, from the first statement.

  A.3.4 Document

    getElementById doesn't state what happens when more than one element
    has the given ID.  This is just one example of the general pattern
    pointed out by Maciej of redefining things from DOM 3.  It would be
    better to reference DOM 3 and then list any changes from those
    definitions, IMO, so that such cases are not missed.

  A.4.7 KeyboardEvent

    keyIdentifier doesn't say what form the identifiers are in.  If the
    intention is to reference DOM 3 Events, remember that it is still a
    note.  Devices supporting SVGT1.2 are likely to have keys not
    present on computer keyboards and thus don't have a corresponding
    entry in DOM 3 Events Appendix A.2.  Will there be any requirement
    for device manufacturers to provide sane mappings from their keys to
    the identifiers in that list?  Or if mapping is not appropriate, how
    will these keys be handled?

  A.7.3 SVGElementInstance

    It states:

      If the 'use' element references a simple graphics element such as
      a 'rect', then there is only a single SVGElementInstance object...

    but elements such as 'rect' can have child elements such as 'desc'
    or 'title'.  Are these intended to be ignored when constructing the
    SVGElementInstance tree?

  A.7.9 SVGMatrix

    The methods for multiplying, translating and scaling are named
    differently from those in SVG 1.1's SVGMatrix interface.  Is there a
    good reason for this?

  A.7.12 TraitAccess

    "Trait manipulation interface." isn't a whole sentence.

    "...will consider the value to be invalid if its 'in error'."
                                                 ^^^
    
    I'm actually not sure if setting traits is meant to change the
    corresponding attribute or not.  It states:

      Setting a trait value has the same effect as changing a
      corresponding attribute...

    yet the effect of changing the corresponding attribute isn't that
    the attribute changes (that's the cause).  I think it should be
    clarified whether the attribute value changes or not, and it would
    make sense if the attribute value was changed.

    It's stated that:

      Implementations that support multiple versions of SVG must allow
      trait access to the most extensive set and support the types
      supported by each trait in the most extensive set.

    Maybe this should be the union of the sets, not the most extensive
    set, since that may preclude some traits from being supported if
    they are present in one of the smaller sets but not the largest one
    (assuming "most extensive" means "has the most elements").  Though
    maybe all SVG versions (except one) will define sets of traits
    that are supersets of or equal to others'.

  A.7.13 Additional accessing rules

    Should the word "none" actually be in bold and single quotes in this
    section?  Is it a literal value that can be passed to setTrait?

    This text:

      These elements can be inserted and removed from the tree but they
      cannot be modified once inserted into the tree.  Manipulating
      animations while they are in the uDOM tree and possiblely active
      would result in undefined behaviour.

    conflicts with what Chris told me in this e-mail:

      http://lists.w3.org/Archives/Public/www-svg/2005Nov/0103.html

    I also still haven't found where the manipulation of animation
    elements' timing attributes is well specified.

Also, all of the code examples on the page have no indenting, making
them hard to read.

Thanks,

Cameron

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org

Received on Wednesday, 4 January 2006 06:40:49 UTC