Re: Microsoft vote [was: Call for Review: XML Events Is a W3C Proposed Recommendation]

Many thanks for your review.

We disagree that device properties should be encoded in markup languages. It
should indeed be possible to target a particular document to a device, but
it
should also be possible to write a document that would work on several
devices.

Furthermore, if some future device comes along with a new type of event, as
for instance TV browsers have, then we think it wrong to have to issue a new
version of all markup languages just to allow documents to be written that
would work on the new device.

That is why we firmly believe that having an extensible event markup is a
fundamental strength and not a flaw.

It is incorrect to state that the specification outlaws use of a schema that
is tighter than the one provided in the spec. The specification says "The
document must conform to the constraints expressed in Appendix B - Schema
Implementation or Appendix A - DTD Implementation, ..." It doesn't say it
has to use those schemas, just conform to the constraints expressed by them.
A document conforming to tighter constraints still conforms to the
constraints in the specification. (However a document conforming to weaker
constraints rightly doesn't.)

That XML Events is not the same syntax as in HTML is by design, since the
HTML style of markup has significant flaws, such as the inability to write a
document that would work on user agents that use different scripting
languages. However, it should be noted that the two notations do not in
principle interfere with each other, so that a document could contain both
markups and still operate correctly, and therefore in a backwards-compatible
way.

Best wishes,

Steven Pemberton
Chair, HTML Working Group

> XML Events suffers from a serious fundamental flaw.  The Introduction
> states as one of the benefits of XML Events, that it overcomes the
> problem of "hardwir[ing] the events into the language, so that to add a
> new event, you have to make a change to the language."  We strongly
> question the premise that this is desirable.  Introducing a new event
> effectively changes a language because a document relying on a new event
> for proper interpretation won't have the same behavior in a processor
> that doesn't understand the new event.
>
> A proper way to check for this condition is to use validation to
> determine as early as possible which events are supported.  XML Events
> is seriously flawed in the way its conformance clauses interact with
> validation mechanisms.  The specification outlaws (section 2.1-1 and
> 2.2) use of a schema that is tighter than the one provided in the spec.
> This bans such useful behavior as restricting the allowed set of events
> to anything less than an infinite set, or restricting certain events to
> certain elements.  This damages the ability to target XML Events to a
> particular grammar, and destroys the utility of validation as the first
> defense against interoperability loss.  We feel strongly that using a
> new event on an old document processor should trigger a validation
> error.
>
> The dubious benefits ascribed to XML Events are used to justify another
> major flaw - that the XML Events syntax is not backward compatible with
> HTML and SVG syntax.  We believe backward compatibility is an important
> goal, and that XML Events does not provide any benefits with which to
> compensate for its loss.

Received on Wednesday, 24 September 2003 06:55:05 UTC