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

Re: Terminology to be used with ITS markup (II)

From: Felix Sasaki <fsasaki@w3.org>
Date: Tue, 24 Jan 2006 21:58:58 +0900
To: "Lieske, Christian" <christian.lieske@sap.com>, public-i18n-its@w3.org
Message-ID: <op.s3vvoktpx1753t@ibm-60d333fc0ec>

Hi Christian,

On Tue, 24 Jan 2006 20:40:57 +0900, Lieske, Christian  
<christian.lieske@sap.com> wrote:

> Hi there,
>
> Please find my comments (starting with "CL>") below.
>
> Best regards,
> Christian
>
> -----Original Message-----
> From: Felix Sasaki [mailto:fsasaki@w3.org]
> Sent: Montag, 23. Januar 2006 15:57
> To: Lieske, Christian; public-i18n-its@w3.org
> Subject: Re: Terminology to be used with ITS markup (II)
>
> Hi Christian,
>
> On Mon, 23 Jan 2006 23:44:36 +0900, Lieske, Christian
> <christian.lieske@sap.com> wrote:
>
>>
>> Dear all,
>>
>> While working on the task to write an introduction to selection
>> (formerly know as "scoping") I made a general observation: from
>> my understanding we might benefit from one or two changes related
>> to the terminology we use.
>>
>> Let's start with the following question:
>>
>> 	What is ITS markup meant to do?
>
> just one remark here: ITS markup can be used without selection, and that
>
> seems to be a quite commen use case. So I don't know if this is the
> right
> question for the section on selection.
>
> CL> I agree with the "ITS markup can be used without selection" bit.
> CL> As mentioned, I found the need to come grips with terminology when
> CL> working on the section for selection. Of course, the section might
> CL> not be the place that ultimately tackles that addresses the
> CL> observations I made.
>
>>> From my understanding, the ITS markup captures information related
>> to i18n or l10n. Following this line of thought, sth. like
>>
>> 	<body its:translate="no" translateSelector="./p">
>>
>> can be analyzed two-fold, namely either as markup or as information
>> captured by ITS markup.
>>
>> With respect to the view "this is ITS markup", we have to dive down
>> a bit. To me, it seems appropriate to destinguish:
>>
>> 	A. Data category identifier: "its:translate"
>> 	B. Data category value: "no"
>> 	C. Data category selector: "translateSelector"
>>
>> The view "this is ITS information" could be captured by prose like the
>> following:
>>
>> 	The ITS markup 'its:translate="no"' captures the information
>> that
>> 	something should not be translated.
>>
>> I wonder if it is just me who senses a need to capture the two
> possible
>> views
>> (markup vs. information).
>
> to make a difference between markup versus information is fine. But I
> don't see the real difference between information and data category
> here,
> since you could say also markup versus data category. In any case, I
> would
> strongly disagree with your differentiation A., B. and C. above, since
> this looks like a semi-formalization of data categories we don't have.
> We
> can discuss that, but not while creating a summary :) . But if you want
> to
> discuss it: what would be A., B. C. for the ruby data category?
>
> CL> To me ITS information and ITS data categories should and could be
> CL> destinguished:
> CL>
> CL> a. ITS information: ITS information in an XML instance or a schema
> CL> b. ITS data category: sth. described in ITS document
> (http://www.w3.org/TR/its/)
> CL>
> CL> I am not sure that we don't have a 'semi-formalization' yet. Doesn't
> CL> section 6 (Markup Declarations) of http://www.w3.org/TR/its/ work
> along the
> CL> lines of a formalization?
> CL>
> CL> What we are lacking from my understanding are a couple of terms to
> talk
> CL> about ITS markup in XML instances or schemas. A slightly different
> view
> CL> on the terms (see A. - C. above) is the following:
> CL>
> CL> 	A. ITS category: "its:translate"
> CL> 	B. ITS value (simple): "no"
> CL> 	C. ITS selector: "translateSelector"
> CL>	D. ITS match: "./p"
> CL>   E. ITS contingent block: 'its:translate="no"
> translateSelector="./p"'
> CL>   F. ITS autonomous block: ITS markup contained in documentRule or
> schemaRule (including the rule elements themselves
> CL>
> CL> With this proposal, and a destinction between simple and complex ITS
> values, a ruby example like
> CL>
> CL> <body>
> CL>  <p>This is about the
> CL>	<its:ruby><its:rubyBase>W3C</its:rubyBase><its:rubyText>World
> Wide Web Consortium</its:rubyText></its:ruby>
> CL> .</p>
> CL> </body>
> CL>
> CL> could be described as follows:
> CL>
> CL> 	A. ITS category: "its:ruby"
> CL> 	B. ITS value (complex): World Wide Web Consortium - implicit
> (via <its:rubyText>)
> CL> 	C. ITS selector: implicit (via "its:rubyBase")
> CL>	D. ITS match: W3C - implicit (via "its:rubyBase")

I see you point - and this could be formalized in RDF very nicely:
its:ruby rdf:type its:category.
its:ruby its:value <its:rubyText>World Wide Web Consortium<\its:rubyText>
its:ruby its:selector its:rubyBase
its:ruby its:match <its:rubyBase>W3C</its:rubyBase>

Your differentiation between A,B,C and D and my RDF formalization make the  
semantic of what we are doing clearer, close to a machine readable way. I  
am just wondering if we want to apply a machine processing to this, or if  
we will only work with I) ITS markup and II) XPath and default rules for  
specific types of markup XPath. I am a little bit afraid that the gap *for  
human readers* between your formalization and what we do with markup and  
XPath is quite wide. Maybe others think different on this. Any opinions?
Best regards, Felix.


>
> Regards, Felix.
>
>>
>>> From my understanding, we would benefit from a distinction (which
> could
>> be captured by using two different terms to talk about it), and an
>> accompanying
>> set of terms to talk about the three possible parts of ITS markup (see
>> above).
>> Of course, I would be in favour of following terminology established
> by
>> other
>> groups (however, so far I have not been able to research into this).
>>
>> Best regards,
>> Christian
>>
>>
>>
>>
>>
>
>
Received on Tuesday, 24 January 2006 12:59:08 UTC

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