SVG12: brief clarification on formal objections

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:

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 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:

  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:

  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

  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

  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.

  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:
    [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:

  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
  <>, 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 <> 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 <>, 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-

  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

  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 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 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 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., 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

      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-

  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 


  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

  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.
  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 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-

  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/ 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-

  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

  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 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 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 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

  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

  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.


Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Friday, 4 August 2006 11:57:28 UTC