Re: SVG12: #text traits

At 04:40 PM 5/22/2005, Bjoern Hoehrmann wrote:

>* Robin Berjon wrote:
> >>   From http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/svgudom.html
> >> section A.2.7 "The result of getting and setting text content via the
> >> #text mechanism is exactly the same as when using the textContent
> >> attribute." This means that this feature is redundant. Please either
> >> explain in detail why it is not redundant and give advice as to when
> >> which of these methods should be used or remove the feature from the
> >> draft to easy implementation, testing, etc.
> >
> >This is a case in which we've had to concede to redundancy in order to
> >obtain compatibility. The #text trait is what is defined in JSR-226, and
> >textContent is the field inherited from DOM 3 Core — we have resolved to
> >support both as we wish to be compatible with both.
> >
> >If you are using the uDOM and don't intend to be compatible with JSR-226
> >(either because you're already using features not present there, or
> >because you're not using Java), then the recommended one is textContent.
> >In all other situations, #text is best.
>
>This does not satisfy me, at the very least this clarification should be
>added to the draft. The #text trait is not defined in JSR-226 as far as
>I can tell, it's only noted in the support table where it is only
>supported for text elements and not for tspan (which is not supported at
>all, it seems), desc, title, metadata, etc. So there is basically no
>compatibility here that could be gained.

Bjoern,
Perhaps the JSR-226 specification could have been more explicit about #text 
beyond just listing it in a table, and perhaps #text was a bad decision, 
but nevertheless:

* #text is clearly a part of JSR-226

* It therefore represents a backwards compatibility issue for the several 
companies (including Nokia and Sun, just to mention a couple, there are 
others also) who have existing JSR-226 implementations and who also want to 
support SVG-t 1.2 down the road. My understanding is that the spec for 
JSR-226 is all done (i.e., all review periods have passed months ago) and, 
as I mentioned earlier, there are commercial implementations that are 
either shipping on phones today or will be shipping on phones shortly (but 
nevertheless it is way too late to consider software changes).

* For better or worse, #text was agreed to after lengthy (and sometimes 
painful) coordination discussions between the JSR-226 Expert Group within 
the Java Community Process and the SVG Working Group within the W3C. 
Formally, it is defined within a JCP spec and thus the decision about #text 
was a JCP decision, not a W3C decision, but the coordination agreement was 
that the JCP would do its best to maintain compatibility with existing SVG 
Recomemendations and the W3C would do its best to make SVG-t 1.2 upwards 
compatible with JSR-226. I was certainly aware of #text at the time these 
coordination activities occurred and I expect so was everyone else on both 
side (JCP and W3C).


>There are also many other incompatibilities, the clarifications for
>SVGElement.id for example are not in JSR-226 and it uses confusing
>legacy methods like addEventListener which are not added to SVG Tiny 1.2
>either, so there is virtually nothing to be gained here.

If JSR-226 uses addEventListener, then I would say that SVG-t 1.2 needs to 
support it also. Probably the same thing for any other incompatibilities -- 
if it is in JSR-226, we need to include it in SVG-t 1.2.

>Please
>coordinate with the Expert Group instead of having such legacy methods
>and incompatibilities. Clearly the Working Group made them aware that
>it is inappropriate to cite SVG Tiny 1.2 as other than work in progress,
>so this should not be a problem at all.

My understanding is that it is much too late to change JSR-226. Note that 
JCP is a different organization than W3C and that JCP has a different 
process than W3C. The only reason that JSR-226 and SVG-t 1.2 are compatible 
at all was because the JCP and W3C members agreed that it was best for the 
world to coordinate and achieve as much compatibility as possible. But 
that's it. The W3C has no formal control over JSR-226 and it is highly 
unlikely that the companies who worked so hard to define JSR-226 and who 
have developed commercial implementations will decide to change their mind 
on #text at this point, especially since it is so easy to just include it 
in SVG-t 1.2.

Jon

>--
>Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
>68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 23 May 2005 19:25:39 UTC