W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

Re: Datacat for inline element

From: Andrzej Zydron <azydron@xml-intl.com>
Date: Sat, 28 Jan 2006 10:51:29 +0000
Message-ID: <43DB4CB1.5030500@xml-intl.com>
To: Yves Savourel <yves@opentag.com>
CC: public-i18n-its@w3.org

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.



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:
>><li><p>some text</p></li>
>><li><p>another text</p></li>
> 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:
>>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:
> ---------------------------------------------------------------------------------------------------


email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
may not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.
Received on Saturday, 28 January 2006 10:44:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:04:08 UTC