This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2808 - Existing locInfo-like markup cannot be mapped using the locInfoSelector method
Summary: Existing locInfo-like markup cannot be mapped using the locInfoSelector method
Status: CLOSED FIXED
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: WorkingDraft
Hardware: PC All
: P2 major
Target Milestone: LastCall20May
Assignee: Felix Sasaki
QA Contact: ITS mailing-list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-07 15:24 UTC by Yves Savourel
Modified: 2006-09-18 04:41 UTC (History)
0 users

See Also:


Attachments

Description Yves Savourel 2006-02-07 15:24:27 UTC
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.
Comment 1 Felix Sasaki 2006-02-08 03:33:03 UTC
See for additional discussion the thread starting at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0119.html
Comment 2 Felix Sasaki 2006-02-16 11:15:46 UTC
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)
Comment 3 Felix Sasaki 2006-02-23 09:40:55 UTC
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 :)
Comment 4 Felix Sasaki 2006-03-22 07:25:31 UTC
This bug can be closed, since we agreed on having a functionality "passing value" for what is here called "mapping".