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

Re: discussion of LC comments on Extensions

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 29 Apr 2003 09:10:19 -0600
Message-Id: <>
To: david_marston@us.ibm.com, www-qa@w3.org

At 11:43 PM 4/28/03 -0400, david_marston@us.ibm.com wrote:

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

I completely agree.  As I said in a follow-up message, I misread the LR 
proposal first time through.

(Note.  I do have concern that "specify how" might be too constraining, 
e.g., forcing decisions in the base standard that might best be decided in 
profiles, or at least over-ridden in profiles.  But that's a matter of 
tuning the wording here.)

>However, this really is a
>requirement to address handling of unrecognized names in those places
>where the product is receiving named items.

Yes, this is a potential problem, in general.  In some cases (e.g., SVG), 
extension elements or attributes which conform to the SVG extension 
mechanism are required to be in another namespace (in satisfaction of 
CP9.4).  This helps to separate extensions from typos and content 
corruption -- it would be an intricate typo that mimics some valid foreign 
namespace bits!  (This is a piece of the rationale for 9.4.)

>Hence, it might actually
>be a checkpoint under the beleaguered GL 3.

Possibly.  We should consider it when we take up the extensions group, as 
well as the postponed GL3 issue.

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

Received on Tuesday, 29 April 2003 11:08:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:21 UTC