Re: Responding to TAG about versioning

Hi David,

Sorry it took me so long to get back at you on this; my comments are
embedded below. FWIW, in the meantine a new version of the finding has
been published at:
http://www.w3.org/2001/tag/doc/versioning-20031116

Le lun 25/10/2004 à 17:27, david_marston@us.ibm.com a écrit :
> As requested, I read through TAG's Proposed Finding "Versioning XML
> Languages" [1], looking at it in QAWG terms. Per the title, it is
> mostly about XML vocabularies (tag sets), whereas the QA Activity is
> examining conformance measurement for all Classes of Product (CoP)
> that may be subject to W3C Recommendations.
>
> Suggestions to TAG
> 
> I think the definition of "extensible" in part 1.1 should be compared
> to and harmonized with the QAWG definition. As you read the rest of
> the document [1], you will need to think about two sources of "terms
> from other vocabularies": proprietary extensions for a particular
> implementation vs. terms from a different vocabulary defined by some
> other standard. Indeed, TAG seems to be concerned mainly with the
> latter. Thus, the notion of "extensibility" is stretched to address
> the question: how should the XFoo WG define their vocabulary if they
> know that vocabularies from other WGs must be used in valid instance
> documents?

Indeed; they focus on extensible vocabularies and how they should be
handled by their respective processor, while the QA WG speaks more
broadly about any type of extensions.

> In Part 5, I think the first Good Practice should be modified to read,
> "The language SHOULD provide for extension in any namespace other than
> its own." This fits with the ensuing discussion (namespace="##other"
> in schemas, etc.) and eases an obvious conflict with SpecGL. Any given
> WG is expected to define their vocabulary completely in any given
> version, and typically prohibits extensions in their own namespace.
> More about that in the next paragraph.

Makes good sense, indeed.

> In Part 8, TAG presents a Constraint regarding "required extensions",
> but that term would be an oxymoron to QAWG. The notion is that an XFoo
> processor might not be able to do anything useful unless it received
> content that goes beyond the XFoo vocabulary. When there are bits of
> the XFoo vocabulary that are required in some contexts but not others,
> QAWG terminology would say that the bits are a "module" of XFoo, or
> perhaps a higher-than-1.0 level. Where the bits come from some other
> vocabulary, that indicates that assessing conformance of the XFoo
> vocabulary is not the same as assessing conformance of the XFoo
> processor, and it would be required that the XFoo WG recognize that
> they have two CoPs with separate conformance requirements. The
> Constraint has to be more wordy, something like "When a processor will
> require the container language to contain elements from designated
> other vocabularies, the container language ! MUST provide a
> must-understand model, and the processor SHOULD use the
> must-understand features of the container language to express which
> other vocabularies are required."

I think that's not the intent of the the TAG finding; the constraint is
not about required extensions in the sense of a required module. 
Let me try to explain what I understand through a real example: SOAP 1.2
defines for its extensibility mechanism 2 attributes "mustIgnore" and
"mustUnderstand". 
When a SOAP processor receives a message containing content in a
non-SOAP namespace, annotated with "mustUnderstand=true", if the
processor doesn't know the semantics of this content, it must abort the
processing of the whole message. (conversely, mustIgnore informs it can
go ahead even it is not understood).

> I have one quick suggestion about the must-ignore policy described in
> Part 2. XSLT template content should be given as an advanced example.
> The template content is a mixture of Literal Result Elements (LREs)
> and directives ("instructions") to the processor. XSLT requires that
> elements in a template be treated as LREs unless the stylesheet
> includes a declaration that makes them into instructions, and certain
> XSLT elements are always declared to be instructions. XSLT also
> specifies must-ignore for unknown instructions and declarations, but
> there is an extra complication in the case of instructions. Thus, the
> processor is only ignoring those elements that came through as
> directives, not all unknown elements.

I guess it makes sense to at least suggest this as another example,
indeed.

Dom

> [1] http://www.w3.org/2001/tag/doc/versioning-20031003
> [2] http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#variability
> [3] http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org