2808 2006-02-07 15:24:24 +0000 Existing locInfo-like markup cannot be mapped using the locInfoSelector method 2006-09-18 04:41:48 +0000 1 1 1 Unclassified ITS ITS tagset WorkingDraft PC All CLOSED FIXED P2 major LastCall20May 1 ysavourel fsasaki public-i18n-its oldest_to_newest 8141 0 ysavourel 2006-02-07 15:24:27 +0000 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. 8160 1 fsasaki 2006-02-08 03:33:03 +0000 See for additional discussion the thread starting at http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0119.html 8281 2 fsasaki 2006-02-16 11:15:46 +0000 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) 8403 3 fsasaki 2006-02-23 09:40:55 +0000 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 :) 8824 4 fsasaki 2006-03-22 07:25:31 +0000 This bug can be closed, since we agreed on having a functionality "passing value" for what is here called "mapping".