This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For the cases where a format has already a locInfo type of markup (like XMLSPEC-i18n which has a locn-alert attribute) there is no way to map this existing markup to the ITS locInfo data category because the content of locInfo is not a finite list of value but user-defined text. So something like: <its:documentRule its:locInfo="" its:locInfoType="alert" its:locInfoSelector="parent:://@locn-alert"/> simply assign empty comments for the targeted conetnt. We would need something like its:locInfo="content-of(@locn-alert)" to be able to use the mapping method.
See for additional discussion the thread starting at http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0119.html
See thread at http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0128.html I have the feeling that there are two requirements here: 1) adding locInfo to some markup 2) Identifying locInfo which is already in the existing document Below I have tried to separate these. 1) can be done - in situ, via its:locInfo and its:locInfoType, or - dislocated, via its:locInfo plus its:locInfoType plus its:locInfoSelector. Example dislocated (already in the draft): <its:documentRule its:locInfo="This p element has to be handled carefully" its:locInfoType="alert" its:locInfoSelector="/body/p[1]"/> 2) can be done only dislocated, e.g. via its:locInfoContent and its:locInfoType In the current ITS tagset draft we have (in example 32): <its:documentRule its:locInfo="" its:locInfoType="alert" its:locInfoSelector="//@locn-alert"/> <its:documentRule its:locInfo="" its:locInfoType="description" its:locInfoSelector="//@locn-note"/> This would be replaced by: <its:documentRule its:locInfoContent="//*[@locn-alert]" its:locInfoType="alert"/> <its:documentRule its:locInfoContent="//*[@locn-alert]" its:locInfoType="alert"/> In that way, we would not have an additional attribute to its:locInfoSelector, but a different one. The benefit: an ITS processor knows 1 "if I see its:locInfoSelector dislocated, I have to add the content of its:locInfo to a node in the XML document which has no localization information yet" (case 1) above) 2 "if I see its:locInfoContent, I have to extract existing localization information" (case 2) above)
Implemented this in the working draft (text and ODD definition), see http://www.w3.org/International/its/itstagset/itstagset.html#locInfoContent . However, I will not close this bug, because I figured out a simpler solution: instead of @locInfoContent with an XPath expression, we could have @locInfoContent="yes". Advantages: 1 identical to @term="yes", in the value of the attribute and its functionality 2 no need for two selector attributes with different semantics (selection with @locInfoSelector versus extraction with @locInfoContent) 3 no need for conflict resolution between multiple locInfo related selector attributes 4 same functionality as @locInfoContent with XPath, but with advantages 1-3 :)
This bug can be closed, since we agreed on having a functionality "passing value" for what is here called "mapping".