Re: Conformance Section

Hi Christian,

On Tue, 31 Jan 2006 20:48:22 +0900, Lieske, Christian  
<christian.lieske@sap.com> wrote:

>
> Hi everyone,
>
> I definitely see conformance related to two entities:
>
> 1. content (e.g. a DTD which implements ITS markup)
> 2. code (e.g. a processor which computes ITS selection)
>
> This, from my understanding corresponds to
>
> 1-FS schema conformance, which encompasses reading and writing
> 2-FS a processor which processes the full semantics of selections
>
> I am not sure, however, that "schema conformance" is the best
> way to talk about content-related conformance. Wouldn't it be
> advantageous

Sorry, what would the advantage be? I see that you are introducing more  
terms (Markup, Document types, ...).
I guess your strategy is quite different from mine: I am trying to 1)  
minize terms as much as possible, and 2) use terms related to concrete  
existing software, e.g. a schema processor. In contrast, you are  
preferring abstract terms like "Markup" (without talking about XML) and  
abstract notions of software.
My "concrete" way of describing conformance is grounded in a perspective  
of an ITS implementor and user: what the implementor needs is a schema  
processor to validate ITS markup. A user needs a schema based editor to  
edit ITS markup. I think it would be helpful to tell the users /  
implementors of ITS as concrete as possible what "products" we produce.
I have a different comment below.

> to destinguish content-related conformance along the
> following lines:
>
> A. Markup
> B. Document types
> C. Module implementations
> D. Documents
>
> One way to come to grips with code-related conformance might
> be to destinguish between
>
> A. Non-interpreting processor
> B. Interpreting processor
>
> The latter would act according to the semantics of the processed
> ITS markup (a translation editor may for example only turn sections
> with information of "its:translate='yes'" into translatable segments).
>
> A cross-classification for conformance (ie. one which is not based
> on the content/code destinction) is related to conformance levels
> (see Francois' requirement). From my understanding one possibility
> for a definition of these levels would be the following:
>
> - list all ITS data categories
> - list all selection mechanisms
> - list all default mechanisms
> - ...
>
> Then, come up with some levels (e.g. level 1, level 2 and level 3) and
> say which of the list elements (see above) need to be available for
> conformance with a certain level. Example for code conformance:
>
> Level 1: implemented support for "its:translate" without explicit
> selector
> Level 2: ...

My list, grounded in
1-FS schema conformance, which encompasses reading and writing
2-FS a processor which processes the full semantics of selection
3-YS/FS the conformance for visualization (you have not said anything  
about that, Christian, do you think it should be dropped?)
would not encompass levels:

- 1-FS a schema is conformant if it allows to use the ITS elements and  
attributes

- 2-FS a "processor" type "only default selection" is conformant if it  
processes in situ data category attributes. That is: it must be able to  
identify the set of nodes which correspond to an in situ category. Example:
<text its:translate="yes">
<p id="p1">...</p>
</text>
A conformant processor of this type must be able to identify the nodes  
<text> und <p>.

- 4-FS a "processor" type "all selection mechanism" is conformant if it  
processes in situ data category attributes, and <documentRule> elements.  
That is: it must be able to identify the set of nodes which correspond to  
an in situ category and to the dislocated described categories.
<text its:translate="yes">
<its:documentRule its:translate="no" its:translateSelector="/text/p[2]"/>
<p id="p1">...</p>
<p>...</p>
</text>
A conformant processor of this type must be able to identify the nodes  
<text> und <p>[1] for the datacategory its:translate="yes", and <p>[2] for  
the data category its:translate="no".
(here I assume that we get rid of the in situ usage of selector  
attributes, which I proposed.)

Christian, if you still want to use your "abstract" methodology ;) , could  
you come up with a complete list of your conformance levels and for each  
level a short test example?
The reason I am asking you is because IMO the conformance criteria are  
nothing but a basis for the development of such test suites. I am afraid  
that the more abstract we define the conformance criteria, the more  
diffult the testing will be.

Regards, Felix

>
> Best regards,
> Christian
> -----Original Message-----
> From: Felix Sasaki [mailto:fsasaki@w3.org]
> Sent: Dienstag, 31. Januar 2006 06:15
> To: Lieske, Christian
> Cc: public-i18n-its@w3.org
> Subject: Conformance Section
>
> Hi Christian, cc'ing to public-i18n-its,
>
> We should reformulate the conformance section, possibly before the next
>
> meeting. I think the last point of discussion was the types of products.
>
> If I remember right, you proposed
>
> 1-CL a reader / writer
> 2-CL a processor which processes the full semantics of selections
>
> I proposed
> 1-FS schema conformance, which encompasses reading and writing
> 2-FS a processor which processes the full semantics of selections
>
> Yves proposed in addition
> 1-YS a "visualizer"(?) which is responsible for the data categories
> "bidi"
> and "ruby".
>
> As an input for our action item, I would propose to have 1-FS, 2-CL
> (which
> is 2-FS) and 1-YS as the products.
>
> If we agree on this, we can talk in more detail what it means to be
> conformant to the products (although I think that will be no big deal I
>
> think).
>
> I guess the discussion point is only 1-CL vs 1-FS? My reason for 1-FS is
> -
> as usual - that I would like to stick to established terminology.
> "Schema
> conformance" and "validation" are in my perspective well established
> terms, whereas "reading and writing" is IMO too general.
>
> Looking forward for the discussion. Regards, Felix.
>

Received on Tuesday, 31 January 2006 12:21:43 UTC