resolution (3/13 conf call): 

The SML WG believes that the current text in the LC draft resolves this issue fully.  I'm changing its status accordingly.

The change in status should cause email to be sent to the originator of this issue, to whom the following request is addressed.

Please review the current LC text and let us know if you agree with this resolution of your issue, by adding a comment to the issue record. Or, if you do not agree with this resolution, please add a comment explaining why. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.

For the record, at its call of 4 April the XML Schema WG endorsed this
comment.  A clear account of the relation between model validity and
schema validity is highly desirable.  Since the issue has been marked
RESOLVED, I will take the SML WG's response to the issue back to the Schema
WG so they can decide whether they believe the issue has in fact been
resolved successfully.

I personally still (March 3 draft) find this whole area of the spec. unsatisfactory.  In particular, section 8 and sections 5.2.1.3 and 5.1.2.3 still do not combine to successfully specify how SML constraint checking and the Schema spec's rules about the propagation of [validation attempted] and [validity] interact.  One serious negative consequence of this is that it's not clear how SML constraints are meant to interact with any references to validity in the schema spec. itself.

resolution in conf call (5/1/08):
Think about cases where schema skips attempt to validate a component and if an SML constraint is attached to such a component. Need to decide if the SML spec needs to identify such cases and decide how to update the spec to handle them.

Folllowing up from comment #4; I agree that there are things to clarify 
here.  (I think HT's query about [validation attempted] is a bit of a red
herring, though.  We neither change that property nor depend upon it; it's
not clear that there is anything to clarify there.)

We have agreed, I think, that it's important to be able to include invalid
documents in a model.  But we also say (section 8 of SML 1.1) that a
model is valid only if all of its docouments are schema-valid (or more
specifically not invalid!) at the root.  I think this means that model
validity includes XSD validity as a sort of subclause:  if any documents
are schema-invalid, then the model is not SML-valid.  (Are we agreed so
far?)  If the model is not valid, it can still be conforming.

But as suggested by Kumar in comment #4, there's another interaction.  
SML model validation depends on XSD schema validity assessment, because SML
constraints apply on elements and attributes in a document if and only if
they are governed by declarations or definitions that carry the relevant
new properties.  XSD 1.0 allows for some variation among implementations
in some cases such as lax wildcards:  an XSD validator is allowed but not
required to check children, attributes, and descendants of an element that
matches a lax wildcard and has no element declaration in the schema.
Recovery from invalid input is also subject to variation.  

We can do either of two things.

1) Add a sentence (or a non-normative Note?) observing that as
a consequence of the implementation-variability allowed by the XSD 1.0
spec, some implementation-variability is necessarily allowed for checking
SML constraints.

2) Specify that for SML model validation, the XSD 1.0 processor used MUST
do fallback to lax validation whenever possible (or MUST NOT).

For what it's worth, XSD 1.1 has less variation in this area.  And it's
easier to understand the variability in 1.0 by looking first at 1.1 and
the terminology it defines.

> [validation attempted] ... We neither change that property nor depend upon it; 
> it's not clear that there is anything to clarify there.

Maybe I'm being utterly dense or hopelessly pedantic, but it seems like simply stating that sort of thing might address the cited concern.

To deal with [validity], trying my best to channel someone I have yet to meet:
When SML says a model is valid (or invalid), is it talking about XML Schema's [validity] property, or a new SML property?  If a new one, what is the relationship between [xs:validity] and what I'll dub [sml:validity], and what values can [sml:validity] take on?

My own personal answer would I think be: [sml:validity], and its possible values are true (valid) or false (invalid); the relationship between xs:validity and sml:validity is in the SML conformance section (summarized from memory, hence may need tweaking: [sml:validity]=true => [xs:validity]=true | unknown , i.e. a valid SML model is always not-schema-invalid ).

(f2f) add as non-normative note (in sml section 8 conformance) the following to clarify relationship between sml validity and schema validity

SML validity entails NOT being Schema-INvalid on the root or any descendant.

SML validity can be non-vacuously checked only after Schema validity assessment, and only on the portions of the subtree for which PSVI is available.  (editors may need to define vacuously or rephrase)

Because the depth of PSVI is implementation-dependent, there is variability in the visibility of SML constraints available to the SML validator, and consequently in SML validity results.

editors: bug should be marked needsReview once text is available in a diff

resolution (6/23 f2f): 

The SML WG believes that the text in comment 7 resolves this issue
fully.  Once the editors have finished updating the spec, we intend to change the status of this bug to FIXED+RESOLVED.

The change in status should cause email to be sent to the originator of this
issue, to whom the following request is addressed.

Please review the proposed text and let us know if you agree with this
resolution of your issue, by adding a comment to the issue record. Or, if you
do not agree with this resolution, please add a comment explaining why. If we
do not hear from you in the next two weeks, we will assume you agree with the
WG decision.

This change has been made according to Comment #7 and is pending agreement or two week waiting period along with review by the WG. 

Proposed change can be viewed in the editor's copy here:
http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml.html?content-type=text/html;%20charset=utf-8#Conformance

I am happy that the current draft has improved sufficiently in this area to satisfy my concern

Make the editorial change suggested by MSM
MSM: suggest to move the first note (in section 8) out of the numbered list, and put it after the existing note

Fixed per comment # 11. Moved the note to the end of the bulleted list to which it applies.
 ===
A model is a conforming SML model  if and only if it satisfies the following conditions:

   1. Each document in the model MUST be a well-formed XML document [XML]
   2. For each XML Schema document in the model's definition documents, the [validity] property of the root element MUST be "valid" when schema validity is assessed with respect to a schema constructed from the "schema for schemas" and the "normative SML schema" schema documents.
   3. All schemas assembled from the XML Schema documents in the model's definition documents MUST satisfy the conditions expressed in Errors in Schema Construction and Structure (§5.1). [XML Schema Structures]
   4. All schemas assembled from the XML Schema documents in the model's definition documents MUST satisfy the conditions expressed in sections 5.1.1.1 SML Constraint Construction, 5.1.1.2 Schema Component Rules, 5.1.2.1 SML Constraint Construction, 5.1.2.2 Schema Component Rules, 5.2.1.1 SML Constraint Construction, 5.2.1.2 Schema Component Rules, 6.3.1 SML Rule Construction and 6.3.2 Schema Component Rules.
   5. Each Schematron document in the model's definition documents MUST be a valid Schematron document [ISO/IEC 19757-3]

Note:

This specification does not define how schemas are assembled and which schema documents contribute to assembling the schemas.