RE: Datacat for inline element

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

Received on Friday, 27 January 2006 04:50:29 UTC