Re: ITS "Products"

Hi Yves,

On Wed, 25 Jan 2006 12:54:34 +0900, Yves Savourel <yves@opentag.com> wrote:

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

yes, that should not happen. So you are right, let's have this product.  
Maybe in the descrption of the product we can say that the details are  
defined elsewhere.

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

Will that issue really come up? After all, for both processing situ and  
dislocated, you will need XPath + additional rules. If you only use in  
situ, you will still need rules for defaults, inheritance and overriding.

Cheers,
Felix

Received on Wednesday, 25 January 2006 04:55:05 UTC