- 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
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