W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

RE: Selection and Ruby

From: Yves Savourel <yves@opentag.com>
Date: Tue, 7 Feb 2006 21:39:05 -0700
To: <public-i18n-its@w3.org>
Message-ID: <002601c62c69$9814b540$0300a8c0@Breizh>

> The functionality is the same as with your proposal below,
> but with less attributes and less ambiguity about whether 
> we have case 1) or 2). What do you think? 

I think it's quite good.
(but I'm sleepy... Maybe I'm mixing up a glaring issue with a brilliant solution :)

It does keep locInfoSelector used in a way consistant as with other datacats.


-----Original Message-----
From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Tuesday, February 07, 2006 8:32 PM
To: Yves Savourel; public-i18n-its@w3.org
Subject: Re: Selection and Ruby

Hi Yves, all,

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
  <its:documentRule its:locInfo="" its:locInfoType="alert"
  <its:documentRule its:locInfo="" its:locInfoType="description"
This would be replaced by:
<its:documentRule its:locInfoContent="//*[@locn-alert]"
<its:documentRule its:locInfoContent="//*[@locn-alert]"

In that way, we would not have an additional attribute to its:locInfoSelector, but a different one. The benefit: an ITS processor
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)

The functionality is the same as with your proposal below, but with less attributes and less ambiguity about whether we have case 1)
or 2). What do you think?


<its:documentRule its:locInfoContent="@locn-alert"

On Wed, 08 Feb 2006 00:38:09 +0900, Yves Savourel <ysavourel@translate.com> wrote:

>> 1. we have a different selection mechanism for Ruby than for other
>> data categories
>> 2. we a selector with contingent ITS markup (put differently:
>> "rubyBase" which serves as a kind of designator for the "target"
>> of the annotation in "rubyText" appears inside the host vocabulary,
>> not in a "documentRule" or "schemaRule")
>> I wonder, if this observation is a valid one and whether we need to
>> act upon it.
> Good point. And this may be a way to find a solution for our problem  
> with mapping locInfo.
> Both rubyBase and locInfo, when used in dislocated way have the common  
> treat that the text information is already in the document.
> Maybe the solution to the locInfo mapping could be an additional  
> attribute for the dislocated rules. We would have something like:
> <its:documentRule its:locInfoContent="@locn-alert"
>  its:locInfoType="alert"
>  its:locInfoSelector="parent:://@locn-alert"/>

solution for 1)

> Where locInfoContent (or whatever name) would be an Xpath expression  
> (relative to the location of locInfoSelector?) that would point
> to the content to use.
> Just a thought.
> -yves
Received on Wednesday, 8 February 2006 04:39:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC