W3C home > Mailing lists > Public > www-qa@w3.org > April 2003

Re: discussion of LC comments on Extensions

From: <david_marston@us.ibm.com>
Date: Mon, 28 Apr 2003 23:43:23 -0400
To: www-qa@w3.org
Message-ID: <OF03411C80.F4DDECD6-ON85256D17.00117911-85256D17.00148013@lotus.com>

LH>I have yet to see an example where extensibility doesn't have some 
LH>interoperability downside.

The only exception I can think of is XML itself! The *Extensible*
Markup Language comes with no pre-defined element names, so it really
is a different creature, more of a blank-slate foundation rather than
a set of features that some users may deem inadequate. For the latter
type, I agree that when interoperability is the goal, vendor-specific
extensions are a problem.

LR>>(2) Add CP to require specs to specify how an implementation should
LR>handle extensions it doesn't understand  e.g., ignore and continue.

LH>Disagree. We do not have the domain expertise, across W3C technologies,
LH>to say what is the best response....This should be the purview of the
LH>individual spec.

But LR's proposal is only to require that the spec say *something* on
the subject, which I think is reasonable. However, this really is a
requirement to address handling of unrecognized names in those places
where the product is receiving named items. Hence, it might actually
be a checkpoint under the beleaguered GL 3. The product won't know an
extension function/element/whatever from a typo. (This is separate
from allowances under GL 9 that the spec can prohibit extensions that
use the namespace URI of the spec's official elements.) Here's a

Checkpoint 3.x: For every set of named objects that can be extended,
state the policy on handling unrecognized names.

Conformance criteria: For each set of named elements, functions,
attributes, keywords, etc. the specification MUST indicate if there is
an extension mechanism which could allow additional items into the set
(even if a different namespace is required). In each case where more
named items could be added, the specification MUST state the policy
on handling unrecognized names.

Rationale: An implementation that doesn't support an extension with a
particular name must handle it somehow. In some cases, raising an
error is appropriate, but the Working Group may also intend that
unknown content be passed through transparently so that a downstream
process can recognize it. In any event, the WG must decide their
policy, so that all implementations will interoperate with respect to
extensions they don't recognize.

When a set of named items is limited to just the fixed list given in
the specification, use of any other name is typically an error.

Lynne, I hope the above verbiage expresses your thoughts on this.
.................David Marston
Received on Monday, 28 April 2003 23:44:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:32 UTC