Re: Snapshot draft of SVG 1.2 released

On Friday, February 27, 2004, 11:28:43 AM, Jim wrote:

JL> Chris Lilley <chris <at>> writes:

JL> | The SVG Working Group is pleased to announce the availability of a
JL> | snapshot draft of SVG 1.2.
JL> |

JL> Great to see it

JL> A few typos etc.

Undoubtedly. There was a publication freeze around the tech plenary,
which was only announced a day before, so it was a rush to get the
document published at all. Dean did a great job and can be forgiven
some rough edges like typos (this time).

JL> The java example in

JL> Still contains an xml:base.

Ok, thanks.

JL> The post example in

JL> // code for today's postURL:
JL> function postURL( url, body, callback ) {
JL>   var req = createURLRequest();
JL>   req.addEventListener( "URLResponse", callback, false );
JL>   req.init("POST",url);
JL>   req.requestText = body;
JL>   req.submit();
JL> }

JL> Also it's not a duplication of postURL since it doesn't pass the same
JL> informatoin back to the callbacks the same, or include encoding and stuff, How
JL> to make a post request would be fine.

I agree its not an exact duplicate of postURL - is that a problem?

JL> The example svg in
JL> contains:
JL> progressBar.setAttributeNS(svgNS, "width", 0);

JL> As logical as that is to my mind, it's not right :-)


JL> Also the sample and text includes "evt.progress", but the IDL, and attributes
JL> description doesn't, just a loaded and a total.

Yes, it didn't get updated in time.

JL> | DOM 3 normalization of attribute values provides both 
JL> | more power and a lower implementation footprint because
JL> | the string form does not need to be stored but can be 
JL> | computed on demand from the internal representation.

JL> Like much of the current draft, this is very good, but shouldn't it be
JL> something the DOM WG are improving?

The DOM WG is turning into a pumpkin, so future work, unfortunately,
is done by those who need it (same as DTDs and Schemas are developed
by those who need them, not by a DTD or Schema WG).

However, the normalization feature I was referring to is
so it is something the DOM WG has already improved.

Consider an attribute that can contain four possible values.
Internally, this can clearly be represented in two bits. However, for
a conformant DOM Level 2 implementation, the entire string complete
with leading and trailing whitespace, cr, etc has to be kept around in
case anyone needs it (which they never do unless they are a a
source-formatting-preserving XML editor, or something).

DOM3 normalization allows the actual semantic to be efficiently
stored, and *a* string representation (not necessarily the original
string) returned on request.

This makes it much more feasible to implement on mobile, as well as
being more powerfuland more useful.

 Chris Lilley          
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Friday, 27 February 2004 08:02:38 UTC