[Bug 6010] [schema11] priority feedback responses

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





--- Comment #4 from John Arwe <johnarwe@us.ibm.com>  2008-09-03 14:26:17 ---
wrt MSM overall reading: 
correct - nothing here I plan to lay in any tracks about, just "feedback" :-)

wrt the confusion on the proximity of the fallback to lax validation and
#defined comments:

SML chose to prescribe fallback to lax in order to have more predictable
assessment outcomes, i.e. to do its best to remove a point of variability in
the results of the schema processors that validating SML consumers inherently
rely on for their functioning.  If SML were to allow processors to choose
"randomly" whether or not descendants of unknown content were assessed, then
SML processors (inherently dependent upon PSVI to evaluate SML constraints)
would more likely differ in their SMLIF validation results wrt a single input
document.  This choice might not mean much to schema processors per se, but
those dependent on schema processors' output need to either propagate this
'surprising' result or remove it.

not-#defined seems like a negation of fallback to lax, in the sense that you
are depending pretty heavily on the ABSENCE of competing schema components.  In
the fallback to lax case I don't really care how much extra cruft the schema
processor wants to keep around -- unused cruft is no harm, no foul (in reality,
market forces incent a minimalist bias probably).  With #defined, I have to
care because it can affect assessment results in the sense of changing from
notKnown or Valid to Invalid.

I certainly acknowledge that in a sense both are dependent on schema processors
doing "reasonable" things to find "the right" schema components.  It seems to
me that "less reasonable" choices on the part of schema processors have a
stronger effect on overall assessment results (document level, what the
majority of processes care about) in the case of #defined than in the case of
fallback to lax.

wrt MSM 3.10.1 If you can think of ways to recast this material...

{complex type definition} (add curly brackets)?  That should at least resolve
the xml vs schema component "question" simply, unambiguously, and consistently
w/ the rest of the document.

As far as the implication that {complex type definition}'s {content type}
includes the {base type definition}'s particles "by definition", I'll readily
admit that I had to return to 3.4.2.3.3 and study it a bit to conclude I agree
with that proposition.  Blame the many varieties of complex type, not the
presentation.  And there is a Note following the tableau addressing exactly
this point already, so the most change I would even consider is linking to that
Note from #sibling.  I leave that possibility to the editors, but I lean mildly
against it on the principle that I (the reader) should read more carefully. In
"real use", I think it's also easy to test and the ("implied") answer is
unsurprising.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 September 2008 14:26:52 UTC