Re: [SpecLite] Managing Normative References

Hi Björn,

This is a very interesting email and again with a lot of materials. We 
will have to brush up a bit.


Le 13 juil. 2004, à 02:55, Bjoern Hoehrmann a écrit :
>   Something that seems to come up quite often in Working Groups is how
> to normatively reference other specification and how the reference
> affects the specification, in particular what happens if the referenced
> specification or parts thereof is changed, updated, obsoleted, super-
> ceded, rescinded, replaced, etc.

	Ok. So let's express that as normative dependencies on a foreign 
technology from W3C or not.


> For example, a specification states
>
>   "The value of the attribute is a URI as in [RFC2396]".
>
> What does that mean for e.g. these examples:
>
>   * ...="http://www.example.org/#foo"
>   * ...="http://[3ffe:2a00:100:7031::1]/"
>   * ...="http://666.666.666.666/"
>   * ...="foo"
>   * ...="http://www.example.org/~björn"
>
> Are these currently legal? Will this change once RFC2396bis "obsoletes"
> RFC 2396? I would say that the first example is illegal as the example
> uses a URI Reference as opposed to only a URI, IMO, RFC 2396 clearly
> distinguishes between those constructs. Others sometimes disagree about
> that. Whoever would be right, it would have been much better if the
> specification said
>
>   "The value of the attribute is a URI Reference
>    as defined in section 4 of [RFC2396]".

	Yes but how do you express the opposite if it was they really wanted 
an URI and not an URI-Reference. So I agree with you that the 
appropriate word are used for the appropriate object.
	It's in the example, you just have given something delicate because 
it's difficult to know the reason why it has been written. Was it 
because there was a lack of knowledge of the editor that an "URI" is 
different from an "URI-reference". Or is is a mistake which has not 
been detected.

	Which techniques, recipes will help to avoid this kind of problems is 
the key. To recommend to people to use the appropriate vocabulary is 
good but without a clever way to "enforce it", it will be difficult to 
improve the quality.

> as that would not allow any argument about it. The second example is
> a bit tricky, RFC 2396 does not include support for IPv6 literals, the
> syntax has been introduced in RFC 2732 which does *not* update RFC 
> 2396,
> even though it is commonly referred to as doing so, e.g. XML 1.0 Third
> Edition states
>
> [...]
>   Definition: The SystemLiteral is called the entity's system
>   identifier. It is meant to be converted to a URI reference (as 
> defined
>   in [IETF RFC 2396], updated by [IETF RFC 2732]), as part of the
>   process of dereferencing it to obtain input for the XML processor to
>   construct the entity's replacement text.
> [...]

Still trying to clarify the issue you raised. :)

Here you are argueing that a W3C Specification makes a wrong assumption 
about another couples of technologies. It's indeed a problem. Again I'm 
not sure how we could solve that. I foresee a possibility under the 
form of a tool but that will be huge to create a kind of copist job.

	Make a database of *all* dependencies among W3C Technologies and their 
external dependencies (like these IETF).

A WG creating a technology, Spec A, and using pieces of another one, 
Spec B, will know all the dependencies that Spec B has accumulated.

> This is also where things get even trickier than above. The definition
> clearly refers to URI References, so
>
>   <!DOCTYPE example PUBLIC "..." "http://www.example.org/#foo">
>   <example/>
>
> would be allowed as "http://www.example.org/#foo" is a legal URI
> Reference. But it is not, the specification points out,
>
> [...]
>   It is an error for a fragment identifier (beginning
>   with a # character) to be part of a system identifier.
> [...]
>
> Well, I complained about this misuse of terminology and the XML Core WG
> told me [1] that using the term "URI Reference" is necessary here as it
> allows absolute and relative references, which, I conclude, the term
> "URI" does not. So it seems that according to their interpretation the
> text proposed first would exclude the fourth example as it uses a
> relative identifier.

Another level in your issue.
* The URI technology identifies two objects, features, which are
	- URI
	- URI Reference
Let's say with namespaces:
	spec:URI
	features:URI
	features:URI-Reference

So I agree with you there's a problem of vocabulary and understanding. 
What will happen when an external specification is ambiguous and you 
still have to use it. How do you solve the problem?

> And actually I was a bit too fast considering the DOCTYPE example above
> as not allowed, it is allowed, the document is, if the processor is 
> able
> to locate the DTD either by using the public identifier or by 
> recovering
> from the erroneous system identifier, both well-formed and valid. And
> yet it has errors. That's an "interesting" problem for authors of
> conformance tools, they would have to write software that says
>
>   The document is well-formed.
>   The document is valid.
>
>   Error: ...
>
> which would likely confuse users...

Yes and no. :) I would say in your analysis is good, but maybe there's 
a third step. A validator is not a conformance tool.

	The document is well-formed.
	The document is valid.
	The document is not conformant.

Exactly like you have a possibility to write well-formed and non valid 
document. Though for some technologies, it's very hard to define a 
conformance tool, specifically when there is meaning requirement in the 
technology.

> The third example is also tricky, the grammar of RFC 2396 allows it, 
> but
> I am not sure how it is supposed to be implemented; anyway, a Validator
> would not probably consider the document valid regardless of this 
> issue.

Yes I guess. A validator is not a conformance tool. :) if we clearly 
define the validator has a tool to verify a document with regard to a 
DTD or a Schema.

> Until RFC2396bis joins these scene, which prohibes this syntax. What
> would that mean? Would my legal content become non-conforming? Would my
> implementation that supports the syntax become non-confofming? Or would
> it be neccessary that the specification gets updated to consider RFC
> 2396bis?

Hmm not necessary it depends on how the reference has been made. If the 
document refers to "RFC2396" as opposed to the "last version of URI 
RFC", which is happening sometimes (I think for example references to 
Unicode) and could be problematic.

> But let us not drift too much from the original issue. So far we have
> seen examples for unclear specification text and disagreement about the
> interpretation of common terminology. Another problem that arises is if
> the specification not only makes unclear references, but also 
> duplicates
> the content of other specifications.

	* unclear foreign specification
	* disagreement on interpretation or misunderstanding
	* unclear references (not precise enough)
	* type of references (this version, or latest version of ...)

> Is an XML 1.1 document an "XML document"?

My first question would be "What's an XML document?" :) Does it exist, 
as on the same line, "What's an HTML document?" Strictly speaking it 
doesn't mean anything without the precise reference to the 
Specification.

I would define an "XML document" as a family of technology now, 
including XML 1.0, XML 1.0 2nd Ed, XML 1.0 3rd Ed, and XML 1.1

> And is the XML 1.0 Recommendation a normative reference of the XHTML 
> 1.0 Second Edition Recommendation?


> Appendix E of XHTML 1.0 SE is "informative", so it seems
> that it is not. The HTML Working Group however assured me that the lack
> of normative references is an error. What the normative references are
> they still have to say...
> What a mess.

Yes we all do mistake, and we are not living in a perfect world. That's 
one of the difficult part of developing specifications. I hope the HTML 
WG will be able to come with an answer. It doesn't mean that it will 
solve your question but at least there will be an answer.

> Hmm, it seems that SpecLite only has
>   http://www.w3.org/TR/qaframe-spec/#reference
> [...]
>   B.3 Make a list of normative (and non-normative) references
>
>   Good Practice: Start now and keep adding to it as you go.
> [...]
>
> That's a bit insufficient... Say I am an editor, how to
>
>   * make a reference so that updates do affect my specification
>   * make a reference so that updates do not affect my specification


Agreed. I will propose you something. Would you mind writing the Good 
Practice for your issue using the template [1] defined for SpecGL and 
you will find many examples in the QA WG Mailing list [2], identified 
by the flag  [SpecGl Draft].

[1] http://www.w3.org/mid/A8A9B604-BB29-11D8-A057-000A95718F82@w3.org
[2] http://lists.w3.org/Archives/Public/www-qa-wg/2004Jul/
	
Make it short and "fun".

> and such. I would like "QA Specification Guidelines" to discuss such
> things to a reasonable extend, please make that happen :-)

You just did it ;). I will put it on the agenda of the next QA Teleconf 
as well.

Thanks Björn.



-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***