#

Issue

Description

Change

Status

1

System Properties

The EG realized that JSR226 1.0 version lacked the definition of system properties that are specific to JSR 226 implementations. System properties are typically used by the application developers to discover or query the API version supported by the underlying implementation.

In this regard, the expert group agreed to add three properties that are considered useful to the developers.

1)      m2g.version

2)      m2g.svg.version

3)      m2g.svg.baseProfile

The following text will be added to JSR 226 overview page to indicate that the following system properties must be supported by the underlying implementations.

1)

Key:

microedition.m2g.version

Description:

The String returned designates the version of the Mobile Scalable 2D Vector Graphics API specification that is implemented. It is "1.0" for this version of the specification

2)

Key:

microedition.m2g.svg.baseProfile

Description:

The String returned indicates the baseProfile of SVG that is supported by the underlying implementation. It is "tiny" for this version of the specification.

3)

Key:

microedition.m2g.svg.version

Description:

The String returned indicates the version of SVG that is supported by the underlying implementation. For example, if the underlying SVG engine is compliant to W3C SVGT 1.1 specification the returned string would be "1.1" and for SVGT 1.2 it would be "1.2" and so on. For more information on the version and the supported feature set please refer to W3C SVG pages http://www.w3.org/Graphics/SVG/

PROPOSED

2

Live SVGRect bboxes

Clarify whether SVGRect for bboxes are live or not for the SVGLocatableElement description. The EG agrees that the SVGRect instances returned be copies of the bounding boxes at the time the method is called and not live.

In the getScreenBBox, getScreenCTM and getBBox methods of the SVGLocatableElement interface, the following text will be added to the return value

descriptions:

getBBox

“The returned object is a copy of the current bounding box value and will not change if the corresponding bounding box changes.”

getScreenBBox

“The returned object is a copy of the current screen bounding box value and will not change if the corresponding screen bounding box changes.”

getScreenCTM

“The returned object is a copy of the current screen CTM value and will not change if the corresponding screen CTM changes.”

PROPOSED

3

Trait access

This issue concerns trait access and what the implementation should do for traits that are not listed in the traits table. The intent in the EG was to allow implementations to go beyond the minimal requirement list i.e. bigger implementations could support more traits than those defined in trait table of SVGElement interface.

In the "Traits supported in this specification, SVG Tiny 1.1 DOM" section, add, after the first sentence:

"Implementations that support multiple versions of the SVG Tiny language must allow trait access to the most extensive set and support the types supported by each trait in the most extensive set. However, content relying on traits or trait types available in future versions may not work in all conformant JSR 226 1.0 implementations".

PROPOSED

4

dispatchMouseEvent event type

This issue is related to dispatchMouseEvent(), where there is a similar crafted wording with the supported event types. The spec. currently allows more event types than click but only click is required.

In the dispatchMouseEvent method, the following text will be added, after the sentence "The only required mouse event type is "click":

"Implementations may support more event types than click. However, using these additional event types may not work in all conformant JSR 226 1.0 implementations"

PROPOSED

5

capturePhase

Currently, the addEventLlistener under EventTarget interface, a DOMException is thrown with error code NOT_SUPPORTED_ERR if useCapture is true since capture phase is not supported in SVG Tiny.

The group agrees to add documention to allow bigger implementations if necessary to support capturePhase but not mandate 226 conformant implementations to support listeners for capturePhase.

The following changes/additions will be made to specification to clarify this behavior.

EventTarget change.

==============

EventTarget.addEventListener & EventTarget.removeEventListener

Modify the documentation for DOMException.

Replace: "DOMException - with error code NOT_SUPPORTED_ERR if useCapture is true since capture phase is not supported in SVG Tiny."

With: "DOMException - with error code NOT_SUPPORTED_ERR if useCapture is true since capture phase is not required in SVG Tiny and implementations may not support registering listeners for the capture phase."

SVGAnimator change.

===============

“Events dispatched by the SVGAnimator are limited to the at-target and bubble phase of the DOM Level 2 event flow (http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-flow)”.

SVGImage change.

=============

In the class description add:

“Note that the DOM event flow resulting from invoking methods such as focusOn or dispatchMouseEvent are limited to the at-target and bubble phase of the DOM Level 2 event flow(http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-flow)”.

PROPOSED

6

Automatic event dispatching by SVGAnimator

Clarify that events are automatically dispatched by the SVGAnimator to the SVGImage

The following text will be added to SVGAnimator class documentation:

“The SVGAnimator dispatches events to the SVGEventListener and automatically dispatches events it detects to the SVGImage.”

Also see issue#5.

PROPOSED

7

Specify the thread for calling dispatchEvents and / or specify the thread in which SVGEventListener listeners are called back.

The SVGEventListener is an abstraction over the platform specific event mechanism (MIDP or AWT events). However, the current 226 specification does not say anything about the thread in which the SVGEventListener is called.

The EG agrees to specify that the SVGEventListener is called in the platform's event thread.

The following wording will be added to SVGEventListener interface description.

“Note:

SVGEventListener implementations are called back in the platform's event thread. In MIDP, the SVGEventListener is called back in the same thread as the one used to invoke event methods on the javax.microedition.lcdui.Canvas class extensions. In AWT, the SVGEventListener is called back in the AWT event thread.”

PROPOSED

8

Issue with invalid SVG content/DOM

The issue is related to the validity of SVG content’s document/DOM structure.

For ex: The following fragment in an SVG document does not conform to SVG schema however, a valid document structure.

<rect ...>

�� <rect .../>

</rect>

The EG has multiple views on how much validation must be performed by the underlying implementations in this regard. After extensive discussions, the group agreed to clarify that such document fragments may be handled differently by different implementations and content developers must be aware of this issue.

The following text will be added to Node interface:

“The methods defined in this interface allow DOM manipulation such as removal and insertion which may lead to the creation of a non-conforming SVG document fragment as described in the SVG1.1 specification, section G2. The rendering of these fragments may be handled differently by different SVG engine implementations, and therefore, it is strongly recommended that any application using this interface ensures that the resulting document is SVG-conformant. An example of non-conforming SVG fragment would be a rectangle inserted as a child of an other rectangle or as a child of an animation.”

PROPOSED

9

BBox of an empty <SVG> and <text> element

The specification lacks clarification on the bbox values for empty <svg> and <text> elements.

For ex: the TCK expects the following:

Empty <svg>:

<svg>

</svg>

BBox: (0,0,0,0)

Empty <text>:

<text x=10 y=10>

</text>

BBox: (10,10,0,0)

The group agrees to return null for <text> and <svg> with no content.

Empty <svg>:

In the description, it is clearly shown that the bounding box of a structure node (such as a group) which contains no children is null. This is described in "Example #6: Empty group". The same behavior applies to the root svg element, which should also return a null bounding box when it is empty.

Empty <text>:

In SVG, the bounding box computation for a text element is based on the cells of the glyphs it lays out:

From: http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox "For 'text' elements, for the purposes of the bounding box calculation, each glyph is treated as a separate graphics element. The calculations assume that all glyphs occupy the full glyph cell."

When a text node has not text content, it has no child glyp to be treated as a separate graphics element. It is similar to a group with no children elements. The JSR 226 SVGLocatableElement explains that the bounding box for an empty group is null. Therefore, the bounding box for an empty text element should also be null.

PROPOSED

10

Missing DOMException error codes

The JSR 226 Document.createElementNS method only documents 2 exceptions

/**

* [...]

* @throws DOMException NOT_SUPPORTED_ERR if the type of element is not supported by the implementation. JSR 226 only requires creation support for some of the SVG namespace elements and only for a limited number of local names in that namespace (see above documentation). Therefore, in a conformant JSR 226 implementation, trying to create elements with a namespace URIs other than the SVG namespace URI and with a qualified name not in the list of required qualified names may result in this exception being thrown.

@throws NullPointerException if <code>namespaceURI</code> or <code>qualifiedName</code> is null.

*/

public Element createElementNS(String namespaceURI, String qualifiedName)

throws DOMException;

This documentation does not cover the case where the qualifiedName has an incorrect syntax according to the "Namespaces in XML" specification.

In the DOM Core Level 2 specification, there is are additional error code thrown when the syntax of the qualifiedName is invalid, which covers that case:

DOMException

INVALID_CHARACTER_ERR: Raised if the specified qualified name contains an illegal character.

NAMESPACE_ERR: Raised if the qualifiedName is malformed, if the qualifiedName has a prefix and the namespaceURI is null, or if the qualifiedName has a prefix that is "xml" and the namespaceURI is different from “http://www.w3.org/XML/1998/namespace"

After discussions within the EG, it was agreed that adding these exceptions would introduce computational overhead for JSR 226 implementations and the use cases for this feature are very limited.

Therefore, the EG has agreed to add the following text to DOMException.NOT_SUPPORTED_ERR documentation under Document.createElementNS:

“Note that a full DOM implementation of the JSR 226 API will throw a DOMException.INVALID_CHARACTER_ERR or a DOMException.NAMESPACE_ERR if the qualifiedName contains illegal characters or is otherwise malformed.

These error codes are not supported in JSR 226, and a NOT_SUPPORTED_ERR code is thrown instead.”

In addition, the group agreed that TCK must only check for DOMException and not the specific error codes.

PROPOSED

11

Relocation of Node with Id

What should happen if an appendChild or insertBefore is called with a newChild or node that has an "id" and is already part of the document tree.� The current spec does not address this issue.

Ex:

1) Node a = getNewNode();

2) a.setId( "a" );

3) Node b = doc.getElementById( "b" );

4) b.appendChild( a );

5) b.appendChild( a );

The API clearly says that (Node.insertBefore):

"If the newChild is already part of the tree, it is first removed."

Now in Node.removeChild, it says that :

"@throws� INVALID_ACCESS_ERR: if the element being removed or one of its decendants have non-null id."

Can we conclude that a Node with Id cannot be relocated?

The main issue was with the interpretation of the term “removed” in Node.insertBefore that could lead to two different behaviors. If this term “removed” implies calling the removeChild() then an Exception must be thrown and otherwise we should not.

Since this is core DOM issue, the EG agreed to clarify the behavior with Mr. Philippe Le Hegaret, chair of DOM working group.

After evaluating the response from Phillippe, the EG agreed that a Node with Id cannot be relocated and therefore the following wording will be added to the insertChild() and appendChild() methods.

insertChild

“DOMException -

with error code INVALID_ACCESS_ERR: if the element being inserted into the tree already has a parent and itself or one of its descendants has a non-null id.”

appendChild

“DOMException -

with error code INVALID_ACCESS_ERR: if the element being appended to the tree already has a parent and itself or one of its descendants has a non-null id.”

PROPOSED

12

render() and releaseTarget()

render()
 - Renders the specified ScalableImage using the supplied anchor point. The anchor point given is relative to the upper left corner of the rendering surface. It is important to note that the content is made visible or flushed to the display only after a call is made to releaseTarget.

releaseTarget()
 - Flushes the rendered ScalableImage to the currently bound target and then releases the target. This ensures that the ScalableImage is actually made visible on the target that was set in bindTarget. Otherwise, the image may or may not become visible.

The issue is that the last sentences in the method description of these two methods (in italic), are contradicting to each other. 

Currently there is also a test in the TCK that does the following:

The test binds the target and then renders an image. Before releasing the target it checks if the image is already present into the targets pixmap. The test expects the image not to be present in the targets pixmap until the target is released based on the description in render() method.

Now, to implement this behavior you will need to have an intermediate buffer on which to copy images at the rendering time and then at the releaseTarget() time to actually copy that buffer onto the targets pixmap. Implementation feedback shows that this is not necessary and has a considerable negative impact on the performance due to a buffer copy operation at each frame in order to pass this test.

Since this is an implementation issue, the resolution was to reword the last sentence in render() method to match the text in releaseTarget() and exclude this test in the TCK.

Replace the following:

"It is important to note that the content is made visible or flushed to the display only after a call is made to releaseTarget."

with

"It is important to note that on implementations, the content may be visible or flushed to the display only after a call is made to releaseTarget."

PROPOSED

13

Clarification on URI format for external resource request

The current spec lacks clarification about the URI format for external request resource.

Ex: For <image> element with href="myImage.png" we require the implementations to compute the absolute URI by applying the xml:base of its parents all the way upto the root SVG element, and pass this back to the implementation of ExternalResourceHandler. There are two cases:

<svg>

��� <image xlink:href="myImage.png" />

</svg>

Case1: The SVGImage is loaded using createImage(InputStream, ..).

In this case, the group agrees the URI that is passed back is "myImage.png" based on the above understanding.

Case2: The SVG Image is loaded using createImage(URL, ...).

What is the expected behavior in this case? i.e if the SVGImage was created using ScalableImage.createImage(“http://www.foo.com/doc.svg”

,…)

should the request for resource be for URI "http://www.fooo.com/myImage.png" or just "myImage.png"?

The EG agrees that the URI format for external resource must include the base URL from which the document was loaded.

The following change will be made under the documentation for requestResource()

Replace URI parameter documentation:

������ �"URI - the URI for the external resource."

With:

������� "URI - the URI for the external resource. The URI must always be computed to its absolute form, to the extent possible. For ex: if the ScalableImage is loaded using an URL, then the computed absolute URI for the requested external resource must include this base URL. For more information please refer to http://www.w3.org/TR/xmlbase/"

PROPOSED

14

Accessing SVGImage in the implementation of ExternalResourceHandler interface

The JSR 226 API was designed such that user would always have a 'valid' SVG document that is not in error. That guided us to have the createImage method throw an exception if the document is in error (and the user does not get an SVG image object) and throw exceptions for methods which would put the document in error.

However, the ExternalResourceHandler is an exception to that approach since it may be called _during_ the image loading process and that raises an issue.

Can the user do anything with the SVGImage instance that is passed to its requestResource() method? For example, can the SVGImage be rendered in the requestResource method implementation?

The EG agreed this to be an issue and the resolution was to� provide additional wording to clarify that SVGImage/ScalableImage instance should only be used for requestCompleted() and using it for any other purposes would lead to an undefined behavior.

The following text will be added to ExternalResourceHandler interface documentation.

“The ScalableImage instances are primarily used to call the requestCompleted() method. Using it for anything else should be carefully considered because requestResource may be called before the SVGImage gets fully loaded (through createImage()), and any method invocation referencing such an SVGImage has an undefined behavior. For example, it is discouraged to create an animator or render the image during the requestResource() call, as their behavior is only defined on valid SVGImages (returned with no exception from either createImage() or createEmptyImage()).”

PROPOSED

15

Clarification for setTrait/setTraitNS

The TCK team’s assumption has been that traits in SVG namespace can be accessed using getTraitNS() with namespaceURI = "http://www.w3.org/2000/svg".

This case was challenged by the following:

=================

In SVG, attributes on SVG elements are not in the SVG namespace. They are in what is called the "per-element type partition":

References: http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName

A.2 XML Namespace Partitions: "In XML documents conforming to this specification, the names of all qualified (prefixed) attributes are assigned to the global attribute partition, and the names of all unqualified attributes are assigned to the appropriate per-element-type partition."

Concretely this means the attributes are in the "null" or "no-namespace"

namespace. In DOM Core Level 2, setAttributeNS(null, attributeName) is equivalent to setAttribute(attributeName).

"Applications must use the value null as the namespaceURI parameter for methods if they wish to have no namespace"

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces

Therefore, getTraitNS(null, traitName) is equivalent to getTrait(traitName).

It should check that getTraitNS([SVG namespace], "target") throws a DOMException with UNSUPPORTED_ERR code.

=================

The EG believes that challenger is making a valid point and agreed to clarify the spec accordingly.

The following text will be added to SVGElement Interface documentation just before "Traits supported in this specification....”:

"Note that SVG traits are in the so-called element's 'per-element type partitions namespaces' (see the "Namespaces in XML" specification, section A.2 [http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName]. Invoking setTraitNS(null, traitName) is equivalent to invoking setTrait(traitName). In particular, this means that the SVG traits are not in the SVG namespace and invoking setTraitNS(SVG namespace,

traitName) is not equivalent to invoking setTrait(traitName).".

PROPOSED

16

Getters for Animator state

Currently, there is no way to query the SVGAnimator for its state.

However, the SVGAnimator throws exceptions when some methods are called while in the 'wrong' state (e.g., calling play() while the SVGAnimator is in the play state). The EG considers adding a getState() method which returns a constant defining the animator's state.

The following will be added under SVGAnimator class:

static public final int PLAYING;

static public final int PAUSED;

static public final int STOPPED;

/**

* @return one of PLAYING, PAUSED, STOPPED.

*/

int getState();

DEFERRED

17

Support for dispatching key events

SVG Tiny 1.1 has a time condition called accessKeys which is very useful for mobile content. However, SVGImage has no method to dispatch key events to the engine.

The discussion resulted in three options for dispatchKeyEvent():

i) dispatchKeyEvent (String event, int keyCode);

������� - The key event is dispatched to the document node. This will invoke the listeners on the root node invoked including the animations (listening to key events) which are registered to the root node.

ii) dispatchKeyEvent (String event, int keyCode)

- The key event is dispatched element in focus. This will invoke the listeners on the focused element and all the parents up to the root node including the animations that are registers to the root node.

iii) dispatchKeyEvent (String event, int keyCode, SVGElement target)

- The key event is dispatched to the specified target element. This will invoke the listeners on the target element and all the parents up to the root node including the animations that are registers to the root node.

Resolution:

The group agrees with option3 where the key events are dispatched to the specified target.

The group agrees to map key codes in MIDP and AWT to DOM Level3 spec.

/**

�* This method is used to dispatch a key event of the specified |type| to a specific target. The key code is platform specific and is mapped to a DOM Events Level 3 key identifier according to the mapping table described in the class description. The only required key event types are "keyup" and "keydown". If a different

type is specified, a DOMException with error code NOT_SUPPORTED_ERR may be thrown. In the case, where the key code value has no corresponding DOM Events Level 3 key identifier (as per the key code mapping table), no event is dispatched.

@param keyCode - the integer code for an actual key on the keyboard

@param |type| - the type of key event.

@param eventTarget - the EventTarget instance on which the key event should be dispatched.

@throws DOMException - with error code NOT_SUPPORTED_ERR if type is not supported.

@throws NullPointerException - if type or target is null.

*/

public void dispatchKeyEvent(String type, int keyCode,���������������� EventTarget target)

DEFERRED

18

Support for MouseEvents

When listening to mouse event, the DOM listeners only get a DOM Event object. It would be good to support MouseEvents so that the handles have access to the event coordinates (see http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-MouseEvent).

The EG considered this feature useful but following� the scope of maintenance, it was decided to add this feature to the subsequent release of this JSR.

The subsequent release of this JSR will subset the MouseEvent interface as defined in DOM Level 3 Events specification.

DEFERRED