- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 04 Aug 2006 13:56:57 +0200
- To: www-svg@w3.org
Dear Scalable Vector Graphics Working Group,
Thank you for informing me [1] about a possible misunderstanding on
part of the SVG Working Group about what constitutes a formal objection
in terms of the W3C Process. As you know, in preparation for advancement
to Candidate Recommendation, the Working Group must, among other things,
report any and all formal objections. Note that there are no longer any
exceptions: even if the reviewer fails to cite technical argument, or
did not specifically re-register his objection if, for example, a group
re-published a Working Draft, the objection still has to be reported.
I believe it to be reasonable for the SVG Working Group to assume that,
unless otherwise indicated, reviewers who express disagreement about how
the Working Group handled a particular issue, would like to have their
disagreement noted when decisions about the future of the document are
made, and that The Director as well as the W3C Membership are interested
in reviewing any dissent; therefore the SVG Working Group should assume
any clear expression of dissatisfaction represents a formal objection,
and ask for clarification if needed (for example, if the group is not
sure what technical argument is being made to support an objection, the
group could ask the reviewer to re-state his argument).
For an example of how to ensure that reviewers are aware of the group's
expectations, as well as the opportunities the W3C Process gives them,
you could have a look at how the Voice Browser Working Group handles it:
http://lists.w3.org/Archives/Public/www-voice/2005JanMar/0032
A simple way to handle this in the DoC is to use only three reviewer
states, reviewer agreed, reviewer disagreed, reviewer did not respond,
and encourage reviewers to indicate they are satisfied with how the
group handled their issue. It is then easy to identify outstanding
dissent for all interested parties.
Below I give a few examples of my formal objections and summarize the
technical arguments I have made to support them. I hope this additional
information will help the Working Group to prepare the advancement of
the SVG Tiny 1.2 Working Draft to Candidate Recommendation status as
required by the W3C Process.
Process issues and their technical adverse effects
The SVG Working Group has a track record in ignoring its obligations
under the W3C Process and its Charter; issues are not being addressed,
accurate summary of issues and responses is not being maintained, the
drafts are not updated regularily, a broad range of reviewers had to
complain on the www-svg mailing list. The latest draft is a perfect
http://www.w3.org/TR/2006/WD-SVGMobile12-20060721/ example of this, it
claims in the Status of this Document section:
The third Last Call Working Draft for this specification resulted
in a number of comments which all have been addressed by the SVG
Working Group, a list of all comments can be found in the Last Call
Comments List.
It should be noted that their "Disposition of Comments" fails to list
more than 80 substantive review comments the Working Group received
between the publication of this draft and the previous draft, as well
as formal objections that have been registered in the context of these
comments; most of these comments have not been formally addressed yet.
For example, there was no reply whatsoever to the following last call
comments, and for all I can tell, the issues could be raised again on
the current draft with little to no change:
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0504
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0488
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0491
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0492
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0501
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0487
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0489
The same goes for the vast majority of comments the group received
prior to the second "Last Call" announcement, most of them have not
been replied to in any way and they have never been documented in any
"Disposition of Comments" document; again, many of these issues could
be re-raised on the current draft with little to no change:
http://lists.w3.org/Archives/Public/www-svg/2005Mar/0007
http://lists.w3.org/Archives/Public/www-svg/2005Mar/0058
http://lists.w3.org/Archives/Public/www-svg/2005Apr/0028
http://lists.w3.org/Archives/Public/www-svg/2005Apr/0014
http://lists.w3.org/Archives/Public/www-svg/2005Mar/0085
http://lists.w3.org/Archives/Public/www-svg/2005Jan/0039
http://lists.w3.org/Archives/Public/www-svg/2005Feb/0074
It should be noted that, while some might argue reviewers still con-
cerned about the issues the Working Group did not reply to in any way,
should have raised them again on subsequent drafts, the Working Group
pointed out on the www-svg mailing list
http://lists.w3.org/Archives/Public/www-svg/2005May/0187
that there is no need to do so, as the subsequent last call announce-
ments were not new ones, but "updates" to the first one, and that "The
comments still apply" and the group is "not allowed to" ignore" any of
the issues, which, indeed, the W3C Process does not allow them to. Yet
the group did nothing about these comments. I also note, as stated in
the message above, the SVG Working Group published a Last Call despite
the fact that it knew about a considerable amount of open issues.
Concerned about the technical and procedural adverse effects of such
pre-mature last call announcements, and the general lack of responses
to technical concerns, I've registered my formal objection to the WG's
decision to do so in
http://lists.w3.org/Archives/Public/www-svg/2005Apr/0255
The Working Group's "Disposition of Comments" implies that I "agreed"
with how the Working Group handled the comment, instead of clearly
pointing out that I've registered a formal objection. It think it is
inappropriate to do so without a clear statement on part of the re-
viewer that he withdraws his objection, and in this case, it is highly
unreasonable to think I would do this, for the Working Group did not
actually do anything about the unaddressed comments.
http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/lc-replies.html#SVGT12-112
It so happens that a great number of issues are mischaracterized in
the two "Disposition of Comments" documents, for example, more than
a dozens of my comments are marked as "no change seemed to be asked
for" whereas I clearly asked for changes in any and all comments, so
it would seem any "Discuss" comment of mine is actually a "disagree".
This already apparent from the very first issue in their latest DoC
document, marked as follows:
http://www.w3.org/TR/2006/WD-SVGMobile12-20060721/lc3-replies-public.html#SVGT12-8
[Disagree] The SVG WG believes the commenter misunderstands transfer-encoding.
[Agree] This comment appears to be the same as SVGT12-159 and was dealt with there.
Following the links provided there, I just pointed out that both of
the responses the Working Group provided do not actually deal with my
concern at all, and the Working Group agreed that the responses they
sent are not relevant to the issue, as indicated in the last message
linked there. So in effect, the Working Group never addressed my
comment, yet I apparently agree and disagree with their decision.
Unfortunately, a great many of the responses I got were technically
incorrect in obvious ways. An example is issue SVGT12-278, where I,
according to the DoC, agreed, disagreed, and requested no change; in
the end, the Working Group claimed "If you want an animation to be
cumulative, it must first be additive." This is incorrect, as kindly
pointed out by Maciej Stachowiak:
http://lists.w3.org/Archives/Public/www-svg/2006Apr/0115
Maciej, unlike the SVG Working Group, also understood my concern,
which I had to give up explaining to the group. The group, instead
of correcting their mistake and addressing the original issue, now
unfortunately added "Note: all animations that are additive are also
cumulative" to the draft; this note is incorrect; an animation can
be additive and non-cumulative at the same time. The original issue
has yet to be formally addressed.
The draft also notes "The SVG Working Group plans to submit this
specification for consideration as a W3C Candidate Recommendation."
This plan asserts that the Working Group made no substantive changes
to the document, only clarifications, bug fixes, editorial repairs,
and minor error corrections.
However, considering that as many as four entirely new appendices
have been added, the #barename fragment identifier format has been
changed in a way that's completely incompatible with SVG 1.1, that
it is no longer possible to register, using markup, event listeners
for events in a namespace, that new features like the 'none' value
of the transform="" attribute have been added, other features like
the .hasFeature() method of the DOMImplementation interface have
been removed, or that the event types of many events have been
changed without even asking the WebAPI Working Group to review the
changes, I find that to be quite a stretch.
Considering the number of outstanding issues as pointed out above,
and considering the issues where I think more work is required, I
think that, in conclusion, the draft cannot reasonably be advanced
to Candidate Recommendation status.
Pre-mature stability claims and commitments
The SVG Working Group rejected a number of change requests concerning
proposed new APIs introduced in SVG Tiny 1.2 because making the change
would cause the SVG Tiny 1.2 Java DOM bindings to be incompatible with
<http://www.jcp.org/en/jsr/detail?id=226>, which specifies a subset of
the new features in the org.w3c.* namespace.
The JSR-226 Expert Group published a "Proposed Final Draft" of their
specification 12 May 2004, two days after the SVG Working Group re-
leased <http://www.w3.org/TR/2004/WD-SVG12-20040510/> which "was timed
to coincide with the publication of the Java Community Process JSR 226
Expert Group's specification". It is the first draft that explains the
interfaces in sufficient detail to actually review them, and also the
first draft that mentions JSR 226.
I understand that the SVG Working Group made a commitment to maintain
binary compatibility between the two specifications. This is, however,
not apparent from their draft, it is not mentioned in their charta,
and is not part of <http://www.w3.org/TR/SVGTiny12Reqs/>, and was only
explained long after the final JSR specification was released and
"millions" of implementations shipped. The Working Group agrees some
of the technical effects are at least "unfortunate".
As an example, the SVGMatrix interface had multiply, translate, scale,
and rotate methods in SVG 1.1, and SVG Tiny 1.2 adds new methods
mMultiply, mTranslate, mScale, and mRotate that achieve nothing but
what could already be easily achieved using the SVG 1.1 methods. Such
differences make it obviously considerably more difficult to implement
both SVG 1.1 and SVG Tiny 1.2 in one software product, and makes it a
lot harder to write content that works in SVG 1.1 and SVG Tiny 1.2 im-
plementations.
I think these "unfortunate" effects could have been avoided if the SVG
Working Group had taken steps to ensure timely and broad review of the
proposed new features and changes, e.g., the features could have been
put into a separate Technical Report to ensure the two organizations
call for implementation at the same time and the requirement to main-
tain binary compatibility between them be clearly documented, and I
think W3C should take steps to ensure this happens when necessary in
the future.
Proposals to limit the unfortunate effects of the lack of review, e.g.
to include the controversial features only in the Java-bindings, have
received little attention by the Working Group, and it is unclear to
me at this point why they have been rejected.
Overlap with WebAPI deliverables
Several new features of SVG Tiny 1.2 are deliverables of the WebAPI
Working Group, in particular, the "Global object" overlaps with the
"DOM Level 2 Views" and the "Window object" specifications, the
Connection interface with a future deliverable for a Socket API, the
Timer interface with a future specification for timed events and the
"Window object" specification, the getURL, postURL, and parseXML
functions with XMLHttpRequest and DOM Level 3 Load and Save, the
progress events with a future deliverable for monitoring the progress
of resources as they are downloaded, and the SVGMousewheel event with
mouse wheel events in DOM Level 3 Events.
The getURL, postURL, and parseXML functions have been implemented as
proprietary extensions in multiple existing viewers, I can accept to
document them in the SVG Tiny 1.2 specification to the extend that
they reflect what is implemented. For the other features I think the
SVG Tiny 1.2 specification is the wrong place to specify them.
The SVG Working Group argued they have to include these features now
as they are needed by their community, and will review specifications
of the competing deliverables during the Candidate Recommendation
phase and perhaps adapt the specification if the competing specs are
found suitable.
It has been repeatedly argued on the www-svg list that multiple SVG
Tiny 1.2 implementations already exist and the implementers just wait
for the W3C to call for implementation to ship the implementations.
Once that has happened, the SVG Working Group is unlikely to make such
changes as they have to maintain compatibility with what they asked
SVG implementers to implement.
Instead, I think the SVG Working Group should address this as follows:
* The Global interface is replaced by a subset of the Window object
(and extensions to it if needed) in coordination with the WebAPI.
While the Window object specification is just a Working Draft, it
is unreasonable to expect major changes to the relevant features
as it merely documents what has been implemented already.
* The Timer interface is replaced by the timer features included in
the Window object specification (setTimeout, setInterval, clear-
Timeout, clearInterval)
* The Connection interface is dropped; it does not support graphics,
most existing SVG viewers, including browsers, do not have support
for such a feature, and major security concerns remain unaddressed
which makes it likely that the feature won't be interoperably im-
plemented. The WebAPI Working Group is expected to work on this
kind of functionality, there is no reason to delay SVG Tiny 1.2
for this feature.
* The progress events are dropped. There are various groups in the
Interaction Domain interested in this kind of functionality, in
particular in the context of streamed multimedia, and given that
this feature is a deliverable of the WebAPI Working Group, I think
that standardization of such functionality should be delayed until
the requirements from the various groups are understood better.
* The SVGMousewheel event is replaced by a reference to DOM Level 3
Events; the SVG Working Group already agreed with this, but then
reconsidered for there is currently no draft available that in-
cludes this feature. We already have a substantial amount of prop-
rietary extensions that address the same functionality, adding an
SVG specific mouse wheel event to the mix is not going to do any
good.
I note that, failing the above, the Working Group also had and still
has considerable opportunity to at least reduce the number of incom-
patibilities between their proposed features and existing specifi-
cations. At the very least, they should do that.
I also note that the SVG Working Group repeatedly argued that they
cannot reference any W3C Technical Report unless it is more mature
than their document, apparently because the W3C Process does not allow
this. This is incorrect, it is up to The Director to decide whether a
group can make normative reference to unstable documents.
Trait API
SVG Tiny 1.2 and JSR 226 introduce a new API meant to allow convenient
typed access to CSS properties and XML attributes in a arguably more
light-weight and simpler fashion than the SVG 1.1 DOM and DOM Level 2
Style (a required feature of SVG 1.1) did.
In http://lists.w3.org/Archives/Public/www-svg/2006Jan/0102.html I've
explained in detail why I think this feature is ill-designed, and the
Working Group never sent any kind of response to many of my concerns.
Now, the design of the SVG 1.1 DOM and DOM Level 2 Style is not that
brilliant either, so there is no ready replacement for "TraitAccess".
The requirement to maintain compatibility with JSR 226 would also make
the removal of the TraitAccess APIs at least difficult.
I think the ideal solution would be to have a general purpose feature
that provides typed access to computed/animated and base values of
CSS properties and XML attributes, but that would take considerable
time to develop, which the SVG Working Group refused to do when asked
long ago. So I think steps need to be taken to limit the damage caused
by the introduction of these features. Without knowing the answers to
many of the concerns I've raised, my understanding of the feature is
unfortunately too insufficient to propse appropriate steps.
Focus navigation
With each Last Call Working Draft the SVG Working Group presented a
new or substantially changed approach at handling focus navigation.
There are many W3C specifications that have similar facilities, in
particular there is http://www.w3.org/TR/css3-ui/ which was used in
the first SVG 1.2 Last Call draft. The latest approach re-uses the
names of the CSS properties specified for CSS Level 3, but does not
make them actual properties (or "presentation attributes") and uses
quite different syntax.
I have repeatedly asked the SVG Working Group to point out why they
no longer found the corresponding CSS Level 3 module appropriate
but haven't actually received a substantial response. I think it is
not acceptable to use the names of the CSS3 properties but different
syntax as that will cause significant confusion, and not to specify
what happens if a SVG document uses both the CSS properties and the
SVG-proprietary attributes.
In addition, I think the problems that make it impossible for the
SVG Working Group to simply re-use the corresponding CSS features,
whatever these problems are, can easily be addressed through co-
ordination with the CSS Working Group and possibly other stake-
holders. If not, it would also be easy to at least change the names
of the attributes to match the syntactic conventions used for non-
presentation attributes in SVG, the previous Last Call draft did
in fact just do that.
XML Events
SVG Tiny 1.2 depends on the XML Events specification; previous drafts
did not simply reference XML Events for this purpose, but changed some
syntactic and functional details and added important clarification.
The latest draft simply refers to the XML Events specification. While
these changes and clarifications are controversial, I consider this
change a serious regression as it will cause implementations to be
less interoperable than they could be.
These problems could easily be addressed in XML Events itself, but
unfortunately the HTML Working Group discontinued maintenance of it
after it has been published as Recommendation. Error reports and
similar comments have since been ignored.
I think the SVG Working Group is well aware of the changes neccessary
and could apply them to the XML Events specification in a reasonable
timeframe in coordination with the WebAPI and HTML Working Groups. To
address this problem, I think publication of such a revised XML Events
specification should be added to the Candidate Recommendation Exit
Criteria for SVG Tiny 1.2.
Event-based animation DOM compatibility
SVG Tiny 1.2 inherits a feature from SVG 1.1 and SMIL 2.1 that allows
authors to specify that certain animations or multimedia objects be-
gin or end when a specific event occurs. The event model used in SVG
Tiny 1.2 is the DOM event model. There are, however, three problems
that cause problems in the interaction between the DOM event model and
this feature (the general syntax goes like begin="event-ref"):
* In http://lists.w3.org/Archives/Public/www-svg/2006Jan/0504 I ex-
plain how the feature is not well-defined in terms of the DOM and
that current implementations do not interoperate for this reason.
I think this needs to be addressed as explained there. The Working
Group did not respond to this concern.
* DOM Level 3 Events introduces the notion of namespaced events to
allow authors, implementers, and language designers to introduce
new events while avoiding event name conflicts. SMIL 2.0 and 2.1
(e.g., http://www.w3.org/TR/SMIL2/smil21-profile.html#q22) allow
specification of the event namespace; the SVG Working Group re-
jected my request to provide the same functionality in SVG Tiny
1.2 because "This addition would change functionality which has
been in the spec since version 1.0, namely that there is no way
to express what namespace event-ref has"; I think this is unsound
and should be revisited.
* In the DOM Event model, each event has an associated short name
and a namespace name (Event.type and Event.namespaceURI). Instead
of simply using these to determine whether a given "event-ref"
refers to the event that is currently being dispatched, SVG Tiny
1.2 has an "alias" system by which different SVG-specific names
are associated with the DOM event type. In addition, many event
names cannot be used to trigger animations.
I believe that additional level of indirection is harmful, not
licensed by the SMIL 2.1 specification, and makes the feature
considerably less useful than it could be. I've repeatedly asked
the Working Group to cite the advantages of this model, but all
they have put forward so far is that this is just what SVG 1.1
did.
I've explained that the SVG 1.1 specification is internally in-
consistent relative to this problem, that there appear to be no
implementations that conform to this part of the SVG 1.1 Re-
commanedation, and that SVG Tiny 1.2 is actually inconsistent
with SVG 1.1. I think that this issue, too, needs to be re-
considered.
I note that these problems are, in part, the result of problems in the
SMIL 2.1 specification, and coordination between the SVG and SYMM WGs
should remove problems in both specifications; ideally these problems
are adressed in SMIL 2.1 and SVG Tiny 1.2 just refers to that.
Document manipulation vs. SMIL timing
SVG Tiny 1.2 introduces a new feature, the timelineBegin attribute,
that allows authors to specify whether the document begins after it
has been fully loaded, or immediately when the viewer starts pro-
cessing it. SMIL 2.1 explicitly does not define timing when timed
elements are added to the document when the timegraph is running and
SVG Tiny 1.2 makes no attempt to define timing either, so this new
feature can do nothing but cause undefined behavior.
The Working Group never replied to my concern. I think that either
the feature needs to be removed, or SMIL timing needs to be changed
such that timelineBegin="onStart" yields well-defined behavior. The
same applies to appendix A.8.13 in the current draft, which implies,
incorrectly, that inserting and removing elements even though the
timegraph is running yields well-defined behavior.
In a comment predating the text in A.8.13 I pointed out that it is
not well-defined what the behavior is supposed to be when timed
elements are manipulated while the timegraph is not running. The
group never addressed my comment, but A.8.13 now suggests that this
would have undefined behavior. I strongly disagree, there is little
to no technical reason to have this restriction when the timegraph
is not running, and would have objected to it if anyone had informed
me of this decision.
animateTransform underspecified
In the following messages
* http://lists.w3.org/Archives/Public/www-svg/2001Aug/0056
* http://lists.w3.org/Archives/Public/www-svg/2005Dec/0232
* http://lists.w3.org/Archives/Public/www-svg/2006Mar/0125
* http://lists.w3.org/Archives/Public/www-svg/2006Jul/0020
Sai Ramanath, Dr. Olaf Hoffmann, Cameron McCormack, and I point out
that various details regarding the animateTransform element as found
in SVG 1.1 and SVG Tiny 1.2 that are underspecified. The Working Group
did not respond to any of the reviewers but me, and the response I got
parts of the smil animation features are not trivial to capture
... Although you might find the definition confusing we believe
it is correct and will leave it as is.
This reponse pre-dates the concerns raised by Olaf and Cameron, and
it seems the Working Group actually agrees that changes are required
to, at least, make the specification non-confusing. I think the group
needs to revisit these issues, for both SVG Tiny 1.2 and SVG 1.1.
Animation involving dynamic keywords
The animation features in SVG Tiny 1.2 are based on the SMIL animation
model; the definition of non-discrete animation, the model depends on
numeric interpolation between multiple values. If there is an obvious
relationship between a given value and a sequence of numeric values,
the animation effect is generally well-defined. There are, however, a
few cases where there is no such obvious relationship. An example is:
<animateColor from="black" to="currentColor" ...
The currentColor keyword refers to the computed value of the color
property; it is possible to map this to a sequence of numeric values,
but it is difficult to determine which, and this sequence is subject
to change over time (e.g., the color property can be animated aswell).
Neither the SVG Tiny 1.2 nor the SMIL 2.1 specification handle this
case in any way, which means it is unclear whether interpolation be-
tween the two values above is possible, when implementations must de-
termine which numeric values "currentColor" maps to, what the effect
of changing the computed value should be, and what happens when the
animation is no longer active, but the effect of a previous iteration
is frozen (i.e., what is actually written into the override style
sheet, it could be 'currentColor' or the derived color value, which
makes a significant difference if the 'color' property is changed).
It can be argued that, because neither specification discusses this
case, and because the dynamic nature of a keyword like currentColor
could be seen to imply equivalent processing as when the animation
element is changed (e.g., the 'to' attribute could be changed from
'red' to 'green' to 'black' while the animation is active using
scripting), which is not allowed by the specification, that such an
animation is, too, non-compliant.
The Working Group however claims, to the extend that I understand
their argument, that this is perfectly legal and has well-defined
behavior; I do not think this is the case and would further argue
that such an animation would be well outside the animation model de-
fined in SMIL. I think the SVG Working Group needs to revist this
issue and find a solution in coordination with the SYMM WG. A good
solution would be to simply require implementations to treat cases
like this as if calcMode='discrete' had been specified.
Use of unregistered media types
The latest SVG Tiny 1.2 Working Draft cites three unregistered media
types video/x-msvideo, application/java-archive, and application/java.
According to RFC 4288 use types in the experimental tree like video/
x-msvideo is discouraged; the Working Group never replied to my con-
cern about this violation of IETF standards.
application/java is used in one example without further comment, I
asked the Working Group to change the specific example to use no un-
registered media type, but the group rejected my concern, so I am
unsure whether this is not supposed to be application/java-archive
instead.
As for application/java-archive the draft requires:
For compiled languages, the xlink:href attribute must reference
a script element that itself references a JAR archive holding a
manifest with an SVG-Handler-Class entry pointing to an
EventListenerInitializer2 implementation.
The only media type indicated as appropriate for use in this case
is the unregistered type application/java-archive. The draft never
explains directly or indirectly through reference the format to be
used with this media type, so I am unsure whether it is appropriate
to require its use for any "compiled language".
I believe it to be inappropriate for W3C Technical Reports to re-
quire or encourage use of unregistered media types, I've explained
in e.g. http://lists.w3.org/Archives/Public/www-tag/2006Jul/0009
the adverse technical effects of doing so, in particular if the
format and media type are not fully defined in the first place.
The group did not cite technical argument to explain why the group
has to use the type even if unregistered, they just informed me
that a request has been made that "SUN" registers the type.
If http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html is to be
considered the specification of the format, it is unclear to me why
a special type for this format is needed, application/zip, which is
registered, seems appropriate to me. As per RFC 4288 multiple names
for essentially the same format should be avoided, it is therefore
also unclear to me that application/java-archive would ever be re-
gistered.
If application/zip cannot be used, there would be alternatives to
the use of application/java-archive, for example, the type attribute
of the script element can be changed so it takes either a media type
or a string like "java-archive", and content providers can omit the
Content-Type header in responses to requests for such resources,
which would allow the receiver to guess. Or application/zip could be
used which, in combination with the type="java-archive" attribute,
might also address the need for an additional type.
It would also be considerably simpler to register a vendor-specific
type like application/vnd.w3c.java-archive or application/vnd.sun.
java-archive, it is again unclear why this is not an option for the
SVG Working Group.
Another alternative would be to use application/x-java-archive which
would clearly point out the unregistered and experimental nature of
the type, it is again unclear why this is not an option either. In
fact, it seems other popular types for this format appear to be
application/jar, application/x-jar, and many others.
In any case, if the Working Group is confident that the type will
be registered soon, it could easily include candidate recommendation
exit criteria to the effect that SVG Tiny 1.2 cannot exit CR with-
out the type being registered. As the Working Group did not offer
anything to this effect, it appears they share my doubt that any
registration will actually occur. Of course, the Working Group could
also just include the registration of the type in the draft and have
it registered through the same process it uses to register the image/
svg+xml media type.
I think the Working Group needs to revisit this decision and at the
least publicly document why none of the options I've cited here are
acceptable for the SVG Tiny 1.2 Working Draft and change the draft
so that it clearly indicates that the type is not registered and is
subject to change, as it did with "text/ecmascript" in SVG 1.1.
image/svg+xml charset parameter
The registration of the image/svg+xml media type omits the charset
parameter common to virtually all XML media types. This will re-
sult in SVG implementations that ignore the charset parameter,
which will contradict current SVG implementations that honor it
when determining the character encoding of the entity as well as
general purpose XML tools that have no specific knowledge about
the type and assume that all XML media types have a charset para-
meter.
This will obviously cause different SVG and XML tools to be non-
interoperable and present a major security risk when multiple
tools look at XML content and disagree about the encoding. XSS
exploits that leverage this problems in HTML implementations and
server-side scripts are quite common.
In addition it is unclear to me from discussion with participants
in the Working Group how this is supposed to affect implementations,
in particular it is unclear to me whether an implementation that
honors or ignores the charset parameter is conforming or non-con-
forming, as mutually exclusive statements on this matter have been
made. If implementations are required to ignore the parameter, any
general purpose XML tool, like the W3C Markup Validator, will have
to have special built-in knowledge about the image/svg+xml media
type even though that would ne unnecessary without this difference.
The +xml convention was established to avoid this precise problem.
The SVG Working Group was unable to provide technically sound ra-
tionale to defend its decision in this case, at least I was not
able to understand what may or not have been trying to convey. I
think the problems I cite are unacceptable and the parameter must
be added; either all +xml types have it, or none of them do.
Microsyntax definitions and schema
A great many of the attributes defined in SVG Tiny 1.2 do not have
well-defined lexical constraints in the specification prose, and
even less so in the RelaxNG schema included in the draft. I asked,
repeatedly, that the lexical constraints be well-defined, including
how to parse them, and that these constraints be reflected in the
schema. The Working Group initially agreed to do this, then told me
"it's an unnecessary burden on the specification editors", and then
told me it's been done, even though the problems remain.
To give an example, SVG Tiny 1.2 has a 'color' attribute that takes
a <color> value or the keyword "inherit". <color> can be, among some
other things, a rgb(...) functional notation. It is defined as:
Integer functional - rgb(rrr, ggg, bbb)
Each integer represents one sRGB color component in the order
red, green and blue, separated by a comma and optionally by white
space. Each integer is in the range 0 to 255. This syntactical
form can represent 16777216 colors. Examples: rgb(233, 150, 122)
(i.e a salmon pink), rgb(255, 165, 0) (i.e an orange).
Just below this section, the keyword "black" is defined using this
syntax: 'rgb( 0, 0, 0)'. This is perfectly legal syntax if the CSS
definition of rgb(...) would be in use, but leading white space is
not allowed per the definition cited above. So is this code wrong,
or the definition? And how about 'rgb(0 , 0 , 0)', is that allowed?
I am unsure what "separated by a comma and optionally by white space"
means, that's why I asked the group to provide grammars for such
definitions instead or in addition to relying on prose. The schema
defines the attribute value just as "string", meaning any value goes.
Another attribute is the 'class' attribute. It is defined as
class = <list-of-names>
This attribute indicates membership in one or more sets.
Multiple set names must be separated by white space characters.
The non-terminal <list-of-names> is not defined anywhere in the
draft; are the any constraints on what a "name" is, other than that
it must not include white space characters? How about leading and
trailing white space, are those allowed? The schema again just says
the value is a "string".
Or the 'type' attribute of the 'video' element, it's defined like
type = "<media/type>"
The video format. Implementations may choose not to
fetch videos of formats that they do not support.
The non-terminal <media/type> is not defined anywhere in the draft,
and it's unclear to me why it's in quote marks, for 'class' as above
the non-terminal does not appear in quote marks. Again, the schema
just says any "string" goes.
The 'handler' element also has a 'type' attribute, it's defined as
type = "content-type"
Identifies the language used for the handler element. The value
specifies a media type, per RFC2045. If a 'type' is not provided,
the value of 'contentScriptType' on the 'svg' element shall be
used.
This time the non-terminal is not even in <...>, and while there is
some attempt to actually define lexical constraints and semantics,
the reference to RFC 2045 is meaningless. I asked the Working Group
http://lists.w3.org/Archives/Public/www-svg/2005Jan/0039 specifically
about this case, but they neither replied nor did anything about the
problem. Again, in the schema, any "string" goes.
SVG Tiny 1.2 requires implementations to ignore an attribute if the
value does not meet the lexical constraints; it is obviously not
possible to comply with this requirement if the lexical constraints
are not actually well-defined; and indeed, as a result, existing SVG
implementations vary greatly in how they handle this.
Likewise, implementation of SVG quality assurance tools becomes most
difficult, the schema essentially cannot be used for validation as it
cannot detect even the most obvious errors, resulting in many false
bug reports from users who expect that a validator can actually per-
form validation; and improving the schema is highly difficult as the
specification leaves so much room for interpretation, resulting in
the constant need to argue with users about different interpretations
of the specification, and the need to update the tools as new infor-
mation becomes available, resulting in complaints by users who per-
ceive the tool as unreliable.
I think the SVG Working Group needs to reconsider its decision that
well-defined conformance criteria are "an unnecessary burden on the
specification editors" and revise the draft such that processing and
legal values of all attributes are well-defined.
xml:id, id attribute, and id DOM attribute problems
SVG 1.1 had a 'id' attribute on all SVG elements and a .id attribute
on the SVGElement interface to associate a unique identifier to an
element. These two had a one-to-one relationship. In SVG Tiny 1.2 the
SVG Working Group tries to use the xml:id attribute instead, but re-
uses the SVGElement.id attribute, causing the DOM and XML attributes
to have a complex relationship.
In trying to resolve this problem, the draft specifies, among other
things, that changing SVGElement.id results in a change to both the
XML attributes. Now, the xml:id Recommendation considers documents
that specify two attributes of type ID, even if they have the same
value, non-compliant. The draft attempts to address this problem by
specifying that if an element has both the id="" and the xml:id=""
attribute set, the id="" attribute should not be considered of type
ID.
I think this is unsound and unlikely to be implemented, and told the
Working Group I would consider to accept this only if the group can
show me that the XML Core Working Group considers this the only
acceptable solution and if SVG Tiny 1.2 has candidate recommendation
exit criteria to the effect that SVG Tiny 1.2 cannot exit CR if any
of the implementations used to demonstrate interoperability fail to
implement this requirement.
The Working Group did neither, and incorrectly claims that I agreed
with their resolution. I think a range of other W3C Technical Reports
will face similar problems, and as it is unclear to me that the XML
Core Working Group actually considers it unacceptable to change the
xml:id Recommendation, I think the SVG Working Group needs to revisit
this decision, especially because they apparently agree with me that
SVG implementations are unlikely to actually implement what they
propose.
I also note that alternate solutions to this problem exist, e.g.,
the .id attribute could just continue to map to the id="" attribute,
and a new attribute .xmlid could be added, that maps to xml:id="";
this would correspond to the SVG 1.1 DOM where similar attributes
exist for xml:space="" and xml:lang="". In any case, the rationale
for the decision needs to be clearly documented by the SVG and XML
Working Groups to ensure other Working Groups are aware of it.
[1] http://lists.w3.org/Archives/Public/www-svg/2006Jul/0209
Thanks,
--
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 Friday, 4 August 2006 11:57:28 UTC