From Jan 22 minutes:
Sandy: suggests that we go through spec and ensure that model validator is change to read "this must be true" and model processor similarly. Essentially refrase in terms of the data.

MSM: question is whether we are talking about a property of the processor or the data. Should not talk about property of the data by specifying what a processor should do.

Group sentiment is that this is covered by the previous bug.

========
Therefore, this bug is also about changing statements from imperative or behavioral style statements to declarative style. E.g. rather than taking about what MUST be done, talk about what MUST be true.

At the 1/22 f2f, we discussed and decided I was to open a bug for the cases described in this comment.  I believe the net change is identical to this bug, however my examples are in SML (not SMLIF) and this bug is scoped only to SMLIF.  Thus I am changing this bug from editorial to needs agreement so the wg has the opportunity to confirm my understanding that this change applies to both specs.  My notes of the discussion of these examples, all SML, suggest the same change (in comment #1) that this bug otherwise would scope to SMLIF only.

SML, 4.2.1 At Most One Target
resolves to more than one target then the model MUST be declared invalid.

SML, 4.2.2 Consistent References
An SML model MUST be declared invalid 

SML, 4.2.3 Identical Targets
(several times) A model validator MUST

SML, 4.2 Reference Semantics
A model validator MUST attempt

Resolution:
Editor to review both specs for the following:
- when talking about data - state what must be true
- when talking about processor - state what must be done

Mark 'needsReview' when done.

Made changes to SML-IF spec in addition to a few minor edits. Also merged sections 5.4.x and 5.4.x. The diff for these changes is at:

http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.111%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.112%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1

The SML spec has not yet been changed.

4.2 URI References
Need to tweak for consistency w/ SML spec per an earlier bug.  Appears this place was missed.  Also check remainder of SMLIF spec for other escapees.
from: the     URI Reference Scheme 
to  : the SML URI Reference Scheme

5.2.1 Embedded Documents
has: If the model/*/document/* element contains only a vacuous document
be careful not to lose http://www.w3.org/Bugs/Public/show_bug.cgi?id=5398#c5 when this change is committed

5.2.4 SML-IF Document Version
from: solely because of     value
to  : solely because of the value

5.3.2 Document Aliases
the interchange set , each document element
based on the diff, looks like a space before the comma was accidentally inserted

5.3.2 Document Aliases
comply with the âabsolute-URIâ production as defined in RFC 3986
something strange happened around "absolute-uri"

5.3.2 Document Aliases
The SML_IF consumers MUST compute the value of {base URI} is computed as follows:
this change seems to be in conflict with the desire to phrase things declaratively.  Old text seems declarative.

5.3.3 URI Reference Processing
Old text seems declarative.  Changing it conflicts, as above.

5.4.3 Schema Bindings
In 2d and 3c, the loss of "impl-defined" is significant and undesirable.  Both also need to be rephrased declaratively, e.g.
2d
from: Otherwise, an SML-IF consumer MAY attempt to retrieve components for N from outside the SML-IF document.
to:   Otherwise, it is implementation-defined whether or not components for N are retrieved from outside the SML-IF document.
3c
from: Otherwise, an SML-IF consumer MAY attempt to resolve include or redefine to schema documents outside the SML-IF document.
to  : Otherwise, it is implementation-defined whether or not included or redefined schema documents are resolved from outside the SML-IF document.
(for consistency, might also consider using either retrieved or resolved in both places)

End of appendix B appears to be cut off...not sure if that is a genuine problem or not.

Reminder to figure out what to do with the terms pointed out in http://www.w3.org/Bugs/Public/show_bug.cgi?id=5423#c2

namely, "processor" and "SML processor".  Some combination of defining them and/or replacing them with defined term(s) is needed.

This change has been made to the SML spec. All "conforming..." phrases are    dropped (except in Conformance section) and processors are now "model    validators".

See the diff at:
    http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.169%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.170%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1

Note these changes were made prior to Comment #5 and #6 being added to the bug.

One more update for this bug in the SML spec. Use the following diff instead of comment #7:
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.169%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.171%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1

(looking at the diff in comment 8)

4.2.3 Identical Targets
from: a model validators MUST obey the following rules.
to  :   model validators MUST obey the following rules.

4.2.6 deref() XPath Extension Function
Model validators MUST provide
while this excerpt is true, this section originally used a different term (model processors) because its conditions apply to deref() xpath function extensions in contexts including but not limited to model validation.  As the note following the steps indicates, these steps are insufficient for model validation.  There is another class of embodiments here, we cannot (based on earlier discussions) usefully say this applies to model validators.

7. Localization of Natural Language Messages
from: >Model validators that support the sml:locid attribute
to  :  Model validators that support the sml:locid attribute
(looks like a > crept in)

Regarding comment #5:
- 4.2 - done

- 5.2.1 - done

- 5.2.4 - done

- 5.3.2 - 1st 2 points are non-issues, they appear only on the diff

- 5.3.2 - 3rd point and 5.3.3 and 5.4.3 - I disagree with suggested changes.
The group should discuss this.

Regarding comment #9:

- 4.2.3 - done
- 7 - done

- 4.2.6 - suggest the WG discuss this

Additional, one further thing I think the WG should discuss regarding the changes to the SML spec: section 4.2.2 contains a statement about SML references that CONTAIN multiple reference schemes.  I understand from Sandy that his resolution to the issue regarding the meaning of "SML Reference" (Sandy's proposal that resolved about 10 issues on this one concept) precluded the use of "contain" or "include" to describe the relationship between a SML reference and a SML reference scheme. 

+1 for the changes except for the following:

[1]
"4.2.5 Null SML References" still uses the term 'processors' instead of 'validators'.

[2]
I agree with comment# 12 by Kirk. Proposed change:

from:
If a non-null SML reference contains multiple reference schemes, ...

to:
If a non-null SML reference is recognized as an instance of multiple reference schemes, ...

[3]
I agree with comment# 9 by John about deref().

The deref() function as currently spec'ed is not aligned with model validation (for example, deref() is allowed to not resolve any scheme). Requiring model validators to support it as spec'ed will create inconsistent validation results.

we should either go back to the original wording or clarify the role of deref() during validation.

[4]
SML-IF should be consistent with SML in terms of declarative usage. I am not sure why some changes conflict with this.

for example, the change:

from:
The value of {base URI} is computed as follows:

to:
SML-IF consumers MUST compute the value of {base URI} as follows:

If there is a good reason for this, then we should use this in both specs. Just to clarify, I do not have a strong bias towards either form. Either is ok with me as long as it is consistently used in both specs.

+1 for the change proposed in item [2] in comment #13. 

I would recommend going back to the original wording in 4.2.6, since an explanation of deref() in model validation may make matters even more complex for the reader.

sandy's proposal:
-----------------

4.2.6 deref() XPath Extension Function 
Model validators MUST provide an implementation of the deref() XPath extension function. This function takes a node set of elements and returns a node set consisting of element nodes  
 
Note: 
This note is non-normative. This section The above describes the behavior required for a general XPath 1.0 deref() library function,  
Model validators MUST provide an implementation of the deref() XPath extension function. In addition to the above requirements for general deref() function implementations, for each SML reference with recognized schemes, deref() in model validators MUST attempt to resolve at least one of the recognized schemes. 
So basically: 
1. Do not talk about model validators or SML processors. As the note suggests, the first half of this section is about a general XPath extension function, instead of an SML processor/validator.
2. Add a paragraph about deref() used by model validators. 
3. Additionally require that at least 1 recognized scheme needs to be checked, to ensure consistent result within the validator. (Without this constraint, one part of the validator, e.g. targetRequired, would think a reference is resolved, while other parts, e.g. identity constraints, would treat the reference as unresolved, if no scheme is attempted by the deref() function.) 

I hope the meaning of the #3 should be clear, but can be improved English-wise. 

Does this sound like the right direction? 


Kumar's small addition:
-----------------------
Add the following as a sub-section to section 4.2 SML Reference Semantics:
---
4.2.x Deterministic evaluation of SML constraints
Each non-null SML reference MUST satisfy all of the following conditions in order to be able to deterministically evaluate SML constraints and rules associated with it.
1.	At most one target
2.	Consistent references
---

Appropriate parts of text above will be links to the relevant sections.

Resolution in 2/21 meeting: 
[1] as in comment #15 
[2] change some text to declarative style as suggested by Sandy

No needsReview

Fixed per comment #16. See diffs at:

http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.180%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.181%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1

http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.131%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml-if.html%3Frev%3D1.132%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1