RE: ITS "Products"

>> 1- ITS processor: an application capable of reading or writing ITS 
>> valid markup, and generating error on invalid ITS markup.
>
> the reading part of this processor is the same as what I called 
> "ITS markup declarations" at http://www.w3.org/Bugs/Public/show_bug.cgi?id=2761
> I think. That is after all a schema validator, right? I don't know 
> what you mean by writing ITS markup? Do we have to define how 
> to write the markup, or can't we just leave that to the user of ITS?

Yes, it's the same but better expressed in Bugzilla (I didn't read it before posting my "products"


>> 2- ITS rendering processor: an application capable of rendering ruby 
>> and bi-di text based on the relevant ITS information.
>
> I don't know if we really want to define such a product. 
> I guess we have to, but maybe we don't need to go into details, 
> because so much work has already been made in other specs (the ruby 
> spec, the HTML spec for bidi).  
> Maybe it would even be enough to point to these specs for the 
> directionality and ruby data categories. In that they, we could get 
> rid of this processor. What do you think?

I guess, ruby and bidi cover a very different type of process than the other datacat. So I was wondering if they need to be
underlined in a specific way. We often have tendency to forget them in our discussions...


>> 3- ITS translation processor: an application capable of identifying 
>> translatable parts of XML documents using all the relevant ITS markup.
>>
>> 4- ITS translation basic processor: an application capable of 
>> identifying translatable parts of XML documents containing only in 
>> situ attributes without selectors. [I'm not sure if we want this one]
>
> I would say "no" :) - because IMO it makes no difference if we 
> have selector attributes or not. There will be a default selection anyway.
>
> So to have 1) and 3) as processors / products would be great.

I suppose the issue about having "processors" that supports only "its:translate" in situ without anything else will come up at some
point. Bu, you may be right: the way to address it may not be by making it a "product".

Kenavo,
-ys

Received on Wednesday, 25 January 2006 03:54:46 UTC