Re: Datacat for inline element

Hello Martin,

On Fri, 27 Jan 2006 10:53:32 +0900, Martin Duerst <duerst@it.aoyama.ac.jp>  
wrote:

>
> Hello Yves,
>
> I'm wordering what you think the inline vs. block distinction
> is needed for. This distinction is to some extent a stylesheet
> issue, i.e. it may differ for different presentations of the
> same content.

Maybe Yves will answer this later differently, but my understanding is  
that this is the fulfillment of the requirement described by Richard at  
http://people.w3.org/rishida/localizable-dtds/#inline-elements , in  
summary:

"There should be a means of indicating whether an element is equivalent or  
not to a unit that will be used for automated translation processing. Some  
elements may contain other elements which are translation units in their  
own right."

Hope that helps. Regards, Felix.

>
> If this is relevant to internationalization and/or translation
> (I'm guessing something to do with segmenting?), it would be
> better maybe to talk about this in terms that are closer to
> our area and clearly identify the relevance to i18n or l10n.
>
> Regards,   Martin.
>
> At 11:08 06/01/26, Yves Savourel wrote:
>
>> Hi,
>>
>> Here are a few ideas for the "inline" data category 9or whatever it  
>> will be called).
>>
>> The idea is to identify element like <b>, <span>, etc. that should be  
>> included in the text runs, contrary to elements like <para>, <li>, etc.  
>> that are often used as delimiter for blocks of text.
>>
>> 1- we could use something akin to the translatibility datacat:
>>
>> <its:documentRule inline='yes' inlineSelector="//b|//span"/>
>>
>> However there are several aspects to take in account:
>>
>> - Is this datacat is inheritable?
>>
>> - Do we need it in situ? (or just dislocated and in schema)
>>
>> If not, maybe the mechanism to use it would be different. A simple  
>> enumeration could do it maybe?
>>
>> ...just thinkin aloud agin.
>> -yves
>>
>
>

Received on Monday, 30 January 2006 05:28:39 UTC