sigh: baby, bath water

[proposal 1] One of the two major *points* of the section was to show xsl:variable for the reasons explained in the text (which asserts that sch:let is NOT equivalent in some interesting scenarios).

[proposal 2] ditto

Therefore I think neither proposal is appropriate, unless the basic premise that sch:let implicitly refers to a document-structure-specific evaluation context is being challenged.

[proposal 3] I think we should fix problems (b) and (c) throughout appendix F; doing so retains the intent and fixes the syntax, which is a good thing.

from: <sch:value-of select="string(u:ID)"/>
to  : <sch:value-of select="string(smlfn:deref(.)/u:ID)"/>
...many occurrences in App F

In this sense, I'm taking on faith the bug's assertion that the context= on sch:rule does not govern the sch:value-of... I'm not a Schematron whiz.  Certainly, having just re-read the Schematron spec, I agree there is a conflict there (deref in one place, not in the other), but I cannot tell for sure which is correct with confidence.  On the surface, "without deref()" sure looks right.

[Schematron excerpt] 5.4.14 value-of element
Finds or calculates values from the instance document to allow clearer assertions and diagnostics. The required
select attribute is an expression evaluated in the current context that returns a string.

Resolution in 5/22 calls is that this needs agreement. Julia to discuss this issue with Valentina

Background From Valentina: 

This section refers to localization support in SML and IF. The original intention was to enable translation for messages or text that is visible to a consumer; also to offer variable substitution support for those strings in such a way that messages could be re-used in different contexts.

The target for localization support was schematron assertion/report messages and IF identity elements.

It is obvious that for schematron messages, sch:let can be used to define a variable in support of var substitution. But this is not possible in the IF case or any other text not involving schematron. So for a generic solution, xsl:variable offers the necessary support.

The main issue here is that the localization support as defined now in the SML narrows down on schematron assertions.

5680 Proposal:

While recent discussions of SML localization support have focused on schematron assertions, the existing specification acknowledges other uses.  SML section 7.1 item 3 mentions Elements in instance documents with textual content as possible uses of locid; SML section 9.1.7 adds any element with textual context, also in keeping with the intent Valentina reminds us of. The SML-IF identity element has been mentioned in discussions as another use of variable substitution with locid. Technically, either xsl:variable or sch:let could be used in any of the existing Schematron examples. Lets note this fact in the text, along with the fact that (in the context of Schematron) the best practice would likely be sch:let since that keeps all the markup processible by any Schematron implementation (versus one that also speaks XSLT). 

Bug 5680: Proposed text change

The sample below shows how substitution variable support can be achieved on Schematron sch:assert messages by using sch:let support. 
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"
            xmlns:lang="http://www.university.example.org/translation/">
    <sch:ns prefix="u" uri="http://www.university.example.org/ns" />
    <sch:ns prefix="smlfn" uri="http://www.w3.org/2008/03/sml-function"/>
    <sch:pattern id="StudentPattern>
<sch:rule context="u:Students/u:Student">
    <sch:let name="var" value="smlfn:deref(.)/u:ID" />
    <sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]"
                sml:locid="lang:StudentIDErrorMsg">
        The specified ID <sch:value-of select="$var"/> does not begin with 99.
    </sch:assert>
</sch:rule>

    </sch:pattern>
</sch:schema>
If the message named by lang:StudentIDErrorMsg is intended for use only in the context of Schematron report/assert elements, this mechanism is sufficient.  If the message is intended for use in contexts that include but are not limited to Schematron report/assert elements, then the preceding syntax is insufficient.  In order to allow re-use of a message exploiting variable substitution in other contexts, a syntax understood both inside and outside of Schematron elements is required.  xsl:variable is one possible choice, made more practical by SMLs requirement that validators support the xslt" query binding for Schematron.  The preceding example, altered in this way, follows.
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"
            xmlns:lang="http://www.university.example.org/translation/">
    <sch:ns prefix="u" uri="http://www.university.example.org/ns" />
    <sch:ns prefix="smlfn" uri="http://www.w3.org/2008/03/sml-function"/>
    <sch:pattern id="StudentPattern>
<sch:rule context="u:Students/u:Student">
    <xsl:variable name="var" value="smlfn:deref(.)/u:ID" />
    <sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]"
                sml:locid="lang:StudentIDErrorMsg">
        The specified ID <sch:value-of select="$var"/> does not begin with 99.
    </sch:assert>
</sch:rule>

    </sch:pattern>
</sch:schema>
The error message in sch:assert and the localization identifier lang:StudentIDErrorMsg can now be re-used in contexts other than Schematron report/assert elements for u:Students/u:Student.  An example of using localization with variable substitution entirely outside the context of Schematron rules is given in [SML-IF 4.1].

In SML-IF section 4.1, modify the paragraph that currently reads like this:  
The identity element provides information applications can use to identify and describe the set of SML documents being interchanged. The baseURI child element is one way

To read like this:
The identity element provides information applications can use to identify and describe the set of SML documents being interchanged.  The description may include human-readable text suitable for display and localization.
<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="http://www.w3.org/2008/03/sml-if" version="1.0">
    <identity>
	<name>
http://www.university.example.org/sml/models/Sample/InterDocReferences
	</name>
	<baseURI>
http://www.university.example.org/Universities/
	</baseURI> 
        <version>1.1</version>
        <displayName sml:locid="lang:ModelVersionMsg">
            SML-IF localization example, model version: 
		<xsl:variable name=vers select=../version/>
        </displayName>
    </identity>

</model>

The baseURI child element is one way...

If I understand this correctly, section 7.1 is non-normative and the use of xsl:variable in schematron rules is allowed by the schematron spec (at least by the fact that we . Therefore this  would fall under "best practices" or "tips". So is this necessary at all for the spec?

I'm ok with keeping the appendix as a best practice so, if we do, my next question is about use of deref(). Appendix F does not specify a schema against which we could determine whether deref() is necessary or not. But if we use Appendix E example just prior to F, then I don't think the deref() is necessary. If the context is Students/Student - Student contains ID as a child.

See email at http://lists.w3.org/Archives/Public/public-sml/2008Oct/0032.html for another option on how to handle this from -yves savourel
For the ITS Interest Group.

Here are suggested actions for moving to closure.

1. Ask for votes on the proposal in comment #3 with the exception of the use of deref. If there is agreement on that we are 90% of the way to done.

2. Have further discussion on the use of deref. (See Ginny's issue in comment #4.)

3. Deal with the suggestion from Yves Sovourel - link in comment #5.
   -- The proposal does not align well with accepted industry practice, e.g. Java resource bundles.  JRBs are as they are to facilitate giving the translation jobs out to the translaters (who typically xlate all strings for a given target language, so it's easier to manage if they have their own artifact to work on). 
   -- This could be moved to a separate bug. It is in the same area but not the same text as the proposed changes for 5680. 

(In reply to comment #5)

On its 2008-11-06 telecon http://lists.w3.org/Archives/Public/public-sml/2008Nov/att-0019/20081106-sml-minutes.html#item07 the working decided to:
(1) defer this issue until after the CR draft is published
(2) move the comment from Yves to a new bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=6245 so this comment from outside the working group can be properly tracked.

In the hopes of getting those around during the holidays to noodle on this so we can fix it by the time we issue our next draft without heroic acts to do so, I offer another proposal based on comments 3 (somewhat loosely) and 4:

- Take Ginny's tack of asserting App E's schema, so we don't need confuse the
  localization section with deref (which in principle, and hopefully in practice, 
  is orthogonal)
- Attack a pile of editorial nits.
- Re-cast the variable substitution text as a best practice.
- Get rid of xsl:variable (ala deref, why complicate it?)
- No SMLIF hits needed with this proposal
- Added placeholder where Yves's content might "naturally" fit

http://lists.w3.org/Archives/Public/public-sml/2008Dec/0035.html

removing julia and pratul from cc since they have moved on and probably have enough email of their own.

The working group decided on its telecon of 2009-01-15 to mark this bug editorial, allowing the editors to make changes according to the attached draft and incorporating comments from the telecon minutes.

Fixed per comment #10, using pdf proposal in comment #8 and Jan 15, 2009 telecon minutes.

There is one issue left. I don't think that "{namespace URI}" or the alterntive mentioned "[namespace name]" is correct (in Appendix F). The URI in question is part of the attribute's value (content) not the namespace of the attribute itself. I'm not sure how to specify this.

For example: 
=====
"The Schematron rule is defined generically, to be consumed by any producer for which a translation file is made available at the location defined by the sml:locid value's {namespace URI}."
===== 

The diff showing the changes is at:
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.276%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.277%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1

This diff is truncated as usual but this time there are actual changes in the truncated section so you will also have to view the editor's copy to see the end of Appendix F.

Suggestions (i.e. I think these might improve readability, but nothing I'd lay in the tracks over):

(1)
Appendix F, between heading and first example, where it talks about model processors "using" languages... that feels 'strange'.

from:
a Schematron rule with the purpose of making the Schematron rule available to model processors using different languages. 

to:
message text resulting from Schematron rule evaluation, allowing a model processor to support multiple locales without changes to either the model processor or the Schematron rules.

So it then reads:
The following example, examples demonstrate how localization can be applied to  message text resulting from Schematron rule evaluation, allowing a model processor to support multiple locales without changes to either the model processor or the Schematron rules.
Summarized below are the benefits resulting from using the sml:locid attribute localization support:

(2) 
Appendix F, between heading and first example, where it talks about rules (vs message text) being agnostic... that feels 'strange'.

from:
   1.       The Schematron rule is language agnostic 
to:
   1.       The Schematron rule message text is locale-independent

from:
aware of the locale of a potential model processor. 
to:
concerned with the rule evaluator's run-time locale.

from:
generically, to be consumed by any producer 
to:
generically, consumable by any evaluator (including a model processor)

So it then reads:
   1.       The Schematron rule message text is locale-independent in the sense that the author does not have to be concerned with the rule evaluator's run-time locale.
The Schematron rule is defined generically, consumable by any evaluator (including a model processor) for which a translation file is available at the location defined by the sml:locid value's {namespace URI}.

(2) 
Appendix F, between heading and first example, item 2

from:
   2.      There is a clear separation between the translation process and the Schematron rule. 
to:
   2.      There is a clear separation between message text translation, Schematron rule authoring, and Schematron rule evaluator code. 

from:
There are no changes required to be applied to the Schematron rule when translations for other languages are made available. 
to:
The Schematron rules require no changes when translations for other languages are made available. The same Schematron rule can be used by multiple evaluators, each supporting a distinct set of languages.

So it then reads:
   2.      There is a clear separation between message text translation, Schematron rule authoring, and Schematron rule evaluator code. 
The Schematron rules require no changes when translations for other languages are made available. The same Schematron rule can be used by multiple evaluators, each supporting a distinct set of languages.  To support a new language, all that needs to be done is to add a new translation file under the location identified by the sml:locid value's {namespace URI}.

(3)
Appendix F, between the first 2 examples (grey boxes, on line)
from: In this          example, the {namespace URI} 
to:   In this concrete example, the {namespace URI} 

(4)
Appendix F, after the second example (grey boxes, on line)
from:      In this concrete example,
to:   Also in this concrete example,
and
from: translation resources. For this specific example, there
to  : translation resources, and                        there
I was getting weary of the "in this concrete/specific" repetition.  I kept the first simply to provide linkage across the example (barely kept it).

(5)
Appendix F, after the second example, numbered list
from: The  http://...lang_fr.txt file contains
to:   File http://...lang_fr.txt      contains

(6)
Appendix F, StudentIDErrorMsg examples
Looks like 1 token per line.  Did MSM's new XSLT do something unexpected?
Also see it happening again a bit later, but not all the time.  Hmmm.

(7) maybe...do what you think is sensible, I could read it as 1 or 2 ex's now
from: F. Localization and Variable Substitution Sample  (Non-Normative)
to  : F. Localization and Variable Substitution Samples (Non-Normative)
With Yves' comment, we now have >1

Changing target to PR from CR since it missed the CR draft.

Fixed {namespace name} in section 7 and appendix F per Sandy. Checked in this change.

See diff at:
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.284%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&doc2=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F~checkout~%2F2007%2Fxml%2Fsml%2Fbuild%2Fsml.html%3Frev%3D1.285%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1#Localization_Sample

Made additional changes suggested in comment #12. 

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

Note that I incorrectly included in the previous version the PR publication date so you will see those diffs here also.

Fix duplicate "is" in Appendix F, 2nd para. No needsReview necessary.

Fixed per comment #16