[Bug 5165] Editorial: numbering of rules and constraints

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5165





------- Comment #6 from cmsmcq@w3.org  2008-01-11 03:48 -------
W.r.t. comment #2:  I think you are right that in principle there is some
danger
that there might be text between two constraints that logically belongs not
in either constraint's sub-section but at the next level up.  In practice, it's
suggestive that the random example taken in comment #1 does not in fact have
any
such text:  there are notes and paragraphs between constraints, but they are
all commentary on the constraints and belong with them in the sub-sections.  
Without having performed any census, I suspect that all (or at least most) 
sections containing constraints follow this pattern, if only because there 
tends to be so little connective prose in them.

W.r.t comment #3:  this editor agrees: almost every constraint would benefit
from an introductory paragraph saying what it does, why it's there, and 
perhaps when it does and doesn't apply.

W.r.t. comment #4: I have the same question, but of course you and I were
both members of the Working Group that wrote the 1.0 spec, so we can 
equally direct the question back at ourselves:  why did we vote to move
forward with a spec in which critical concepts appear not as the content of
the definition of a term but as the content of a 'constraint'?  (QName
resolution provides a convenient example.)  You and I are as responsible as 
anyone.

For what it's worth, I think the 1.0 text appears to reflect a particular
way of thinking about validation as the construction of a coherent story
about the validity of the document.  For the story to count as coherent,
this and this and this must be true.  Definitions and constraints are talked
about as if they could only ever be of interest in the course of proving that
a particular PSVI provides a coherent story; the term 'must' makes no sense
if we regard ourselves as describing what QNames in schema documents denote
(they denote X and not Y, there is no 'must' about it) -- but it makes more
sense if we view ourselves as describing what has to be true in order for the
story to make sense and be an officially blessed story about the schema
validity of a particular instance against a particular schema.  In that
situation, what must be true of a particular QName?  It *must* resolve to
(denote) a particular component in the schema.

I am not entirely certain of this analysis, and I'm not sure that it explains
everything in the wording of 1.0, but it does at least tend to explain how
it could conceivably come about that a definition might be formulated as if
it were a constraint.

I think the spec would be clearer if all the definitions in disguise were
reformulated as definitions, but that might in some case lead to the 
complete disappearance of a constraint; it's not clear to me that the WG
will be willing to countenance such changes in all cases.

Received on Friday, 11 January 2008 03:48:23 UTC