Appendices in the vocab document should have been marked informative

w3c / web-annotation

Web Annotation Working Group repository, see README for links to specs

https://w3c.github.io/web-annotation/

Other

142 stars 30 forks source link

Appendices in the vocab document should have been marked informative #354

Closed iherman closed 8 years ago

iherman commented 8 years ago

Per conformance clause sections (ie, appendices) are normative unless noted otherwise. This has not been done and that is clearly an editorial mistake (e.g., the JSON-LD Frames are not a standard, so the cannot be referenced normatively...)

@azaroth42

azaroth42 commented 8 years ago

I think the normativeness of the appendices are:

A Context: Non-Normative [edit, from discussion below]
B Frames: Non-Normative
C Motivations: Non-Normative?
D Exit Criteria: Non-Normative
E Changes: Non-Normative
F Acks: Non-Normative
G Refs: Non-Normative? [created as Normative by respec?]

Model appendices look correct, and Acks in Protocol should be Non-Normative.

Thoughts?

rtroncy commented 8 years ago

The "normativeness" of a json-ld context has been discussed during a breakout session at TPAC, see also the minutes and this proposal: https://www.w3.org/2016/08/namespaces/

azaroth42 commented 8 years ago

After reading the discussion, the context can't be normative because the ontology definition isn't directly normative (the human readable form is). However... the human readable form of the context IS normative (being TR/annotation-model, compared to TR/annotation-vocab for the ontology), so it would be a bug if the non-normative context does not accurately represent the normative model, in the same way that the namespace not representing the normative vocab would be.

Right?

(FWIW, I'm also -0.9 on random working groups adding or modifying ontologies or contexts for that matter)

iherman commented 8 years ago

@azaroth42, you are right. But that is also a practical reason why the context appendix should stay non-normative. If a (programming...) but appears in the context file on /ns that needs fixing after the Rec is published, then we have the freedom of fixing it, and that is essential because it makes software out there working. That also means that a discrepancy appears between the context file as appears in the document and the 'real' document on /ns. But as everything is informative, that is not a real problem. The situation would become more touchy if the context appendix were normative; in theory, that would imply that one should not change the file on /ns either...

Long philosophical discussion ahead:-) which I think we should avoid. Let us keep that informative, in my view...