Re: Datacat for inline element

Hi Andrzej, all,

For the time being - and since the said that we would like to have this  
data category in the new draft to be published at the end of February -, I  
would like to make the following alternative proposals:

a) an attribute @its:inlineElement with the value "yes", and an attribute  
@its:inlineElementSelector with the usal XPath. Sample XPath values could  
be "//[el1 el2 el3]"

b) an attribute @its:inlineElements with the list of elements, e.g. "el1  
el2 el3".

Advantage of b): easy to use. Then processed, s.t. like  
//[$contentOf@its:inlineElements] has to be produced. Disadvantage: It is  
not possible to make the difference between e.g. /html/body/p/el1 (el1  
would be an inline element) and /html/body/el1 (el1 would be not an inline  
elemnent).

Disadvantage of a): you need two attributes, and people have to use XPath.  
Advantage of a): you can make differences between two occurences of el1.

I cannot judge what we need, a) or b). Although from the discussion below  
a) seems to be more likely, also because of the non-inheritence aspect of  
"inlineness".

Regards, Felix.

  On Sat, 28 Jan 2006 19:51:29 +0900, Andrzej Zydron <azydron@xml-intl.com>  
wrote:

>
> I totally agree with Yves. I have spent the past 5 years embroiled in  
> this subject.
>
> Although you can easily identify elements that appear within mixed  
> content, many important document types allow nested elements (XHTML,  
> DocBook, DITA). This allows most elements to appear within mixed content.
>
> The only way around this is to declare an explicit list of inline  
> elements, as was the case for XHTML within the XLIFF TC. The is no  
> automated way of doing this.
>
> An additional problem is the use of the extension mechanism in DITA. An  
> element that is inline in nature in the main DITA specification, may  
> well cease to be so in an inherited and extended implementation.
>
> I will be tackling my action to start work on this topic over the next  
> few days. My current view is to use a dual mechanism that allows for the  
> declaration of an element to be inline regardless, or to be able to  
> qualify the declaration by means of XPath expressions.
>
> Regards,
>
> AZ
>
>
> This subject is fundamental to ITS.
>
> Yves Savourel wrote:
>>>> 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.
>>>
>>> Just a question for clarification: Is it necessary to test whether  
>>> s.t. is an inline element, that is if it part of an element with mixed  
>>> content. As I said during the last call,
>>> such a test would be only an approximation, because you cannot be sure  
>>> without a schema if you have missed e.g. the "inlineness" of the <p>  
>>> elements in:
>>> <ul>
>>> <li><p>some text</p></li>
>>> <li><p>another text</p></li>
>>> </ul>
>>   I'm not sure if I understand the question :(
>> If you mean "are inline elements are always in mixed content?" the  
>> answer is yes (I think). But, as you say: we can be sure of
>> inlineness just by looking at the documents, so testing for it in the  
>> document is not good enough.
>> That why we need the list off all ineline elements.
>>
>>>> 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?
>>>
>>> I would say "no". For example, in some markup schemes lists are  
>>> allowed in mixed content elements, e.g. as part of <p>:
>>>
>>> <p>My ideas:
>>> <ul>...
>>> <li>...</li>
>>> ...
>>> </ul>
>>> </p>
>>> so a list would be an inline element, I guess? But this feature does  
>>> not inherit e.g. to the <li> element.
>>   Difficult to say. If it is, then <li> content should be treated as  
>> "sub-flow". That goes back to the question of nesting things... I
>> guess we may have to plan for cases where an element will be sometimes  
>> inline, sometime not... And identifying sub-flow should
>> probably part of the inline solution too.
>>
>>>> If not, maybe the mechanism to use it would be different. A simple  
>>>> enumeration could do it maybe?
>>>
>>> Enumeration? what would be "bad about the "//" in   
>>> "inlineSelector="//b|//span"? They are the only difference to an  
>>> enumeration :)
>>   Well, the way to process them would be quite different: XPath vs  
>> simple comparison between an element in the list and the current
>> element. But that would probably be too limitative (?)
>>   -yves
>>    
>> ---------------------------------------------------------------------------------------------------
>> Text inserted by Panda Platinum 2005 Internet Security:
>>   This message has NOT been classified as spam. If it is unsolicited  
>> mail (spam), click on the following link to reclassify it:  
>> http://127.0.0.1:6083/Panda?ID=pav_42819&SPAM=true
>> ---------------------------------------------------------------------------------------------------
>>
>
>

Received on Monday, 30 January 2006 05:53:09 UTC