RE: Local support for "Elements Within Text"

Hi Ingo,
 
Thanks for following up on your input of last teleconference,


> It may be beneficial to support the ITS data category 
> "Elements Within Text" at the local level.
> Supporting this at the local level would mean that a simple 
> parser (which does not have to deal with XPath statements) 
> could be written.
> Needing a complex parsing procedure may put some people off 
> using ITS.
> Segmentation information is important to many editing tools, 
> and having this at the local level is of benefit to these 
> tools (if and when they support ITS).

Obviously, one of the reasons why the current version of ITS does not have support for local Elements Within Text rule is because we
found only very rare cases where an element would have to change its 'within text' property inside a document, as this would means
the element has suddenly different semantics. And the examples you gave indicate no differences on that aspect.

The main issue I see with your proposal is that the rational for adding a local Within Text rule seem solely based on making things
easier for the ITS processor.

So I've tried to imagine how this would help:

Having a processor that support Winthin Text only at the local level would means it can only process documents where every single
element that is either 'within text' or 'nested' would have to be marked up as such. Every bold, italic, every span-like elements...
This seemed a bit un-realistic to me.

Then I thought about default attributes in DTDs.

I guess one could argue that a DTD could define the default its:withinText attributes for each element where it is required and this
would result on a document where each element has that information at the attribute level, and this not being related to any real
local change. It would be simply a different way to pass the 'global rules' to the document. And this would allow an ITS processor
supporting only local rules to handle ElementWithin Text.

I am not sure this is a scenario I would recommand to anyone: Default attributes have their own set of issues. But it is a possible
case.

Now, I'd like to hear other people's opinion on this. This is an interesting case.

By the way, It reminded me that an implementation of an ITS processor had to handle such case for other data categories like
Translate: That default attributes should be overriden by global rules, while non-default attribute should override the global
rules. Thanks for the reminder.

Cheers,
-yves

Received on Wednesday, 11 June 2008 13:57:22 UTC