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

Segmentation Hints

From: Yves Savourel <yves@opentag.com>
Date: Fri, 3 Feb 2006 22:23:00 -0700
To: <public-i18n-its@w3.org>
Message-ID: <001c01c6294b$116a8f40$0300a8c0@Breizh>

Hi everyone,

I've been thinking about the inline/block problem and Martin's and Richard's input for the past few days, and from their remarks
I've tried to take a different approach. (See http://esw.w3.org/topic/its0601ReqInlineElements).

As for the realization of such requirement, here are some thoughts:

Maybe the solution could be mixture of information from one data category and inference from the location of the elements in
relation to each other. We could have something like this:

Given the root element would be a type 1, from there we can go through each element:

- if the parent element is not a type 2:
	- if the current element is not a type 3 or 4 then it's a type 2 (nested)
	- else it's a type 3 or 4
- else (we are not within a type 2 element)
	- if the current element has one child node of type 3 or 4, or a text node then it's a type 2
	- else it is a type 1

...I think.

So the only types we have to identify would be the elements of type 3 and 4 (things like <span> or <img>).

The a data category representation for this could be something like:

- segInfo="typeIMG|typeSPAN" (or whatever appropriate values)

- segInfoList="elem1 elem2..." I'm guessing we don't need XPath for this, or only for really strangely design document formats where
you would have things like: <span type="para"> and <span type="strong">, etc.). But maybe a segInfoSelector would be better...

And (I think) no in situ construct is needed for this data category.


One of the problems I can think of is that you cannot randomly access an element and know easily if it's of type 1 or 2. But that's
a problem we found with any mechanism that rely on parent look-back or inheritance.

Note that I haven't tried to code any of this so maybe I'm missing a lot of issues.

Cheers,
-yves
Received on Saturday, 4 February 2006 05:23:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC