I have a question regarding the behavior of sml:locid, specifically the mechanism used to resolve the value of sml:locid to a localized message string.. I've searched the list archives and didn't find anything that addresses this question (although I may have missed the relevant message(s)).
The current draft of the SML 1.1 spec (http://www.w3.org/TR/2008/WD-sml-20080912/) characterizes the resolution mechanism -- i.e., the procedure used to obtain a localized message from the QName value of sml:locid -- as implementation dependent. Since sml:locid only partially identifies a resource on the Web, how can a model author be sure that two separate model validator implementations will retrieve the same resource, the correct resource, or any resource at all?
Consider this rule fragment adapted from the example in appendix F of the SML spec:
<sch:assert test="smlfn:deref(.)[starts-with(u:ID,'99')]"
xmlns:lang="http://www.university.example.org/translation/"
sml:locid="lang:StudentIDErrorMsg">
The specified ID <sch:value-of select="string(u:ID)"/> does not begin with 99.
</sch:assert>
The rule is locale-independent, and that's a good thing since it allows reuse of the rule in multiple locales. But without a specific, defined resolution procedure, a model validator is pretty much free to do anything with sml:locid and/or the lang namespace declaration. For example, given the above rule and $locale as the run-time value of the locale (known to the validator, but not the modeler), a model validator could plausibly resolve the sml:locid in any one of the following ways:
- Get http://www.university.example.org/translation/$locale#StudentIDErrorMsg over HTTP
- Get http://www.university.example.org/translation/$locale/StudentIDErrorMsg over HTTP
- Get http://www.university.example.org/translation/StudentIDErrorMsg?$locale over HTTP
- Look up {www.university.example.org, StudentIDErrorMsg, $locale} in a local catalog of messages
- ... and so on
I understand that sml:locid is an optional feature of SML, so a model validator is free to ignore sml:locid wherever it appears. But certainly those model validator implementations that do support sml:locid must do so in a consistent, interoperable fashion.
Thoughts?
Thanks,
Len