- From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
- Date: Wed, 4 Jan 2006 17:40:35 +1100
- To: www-svg@w3.org
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