Mapping...

Hi all,

Something has been bugging me about 'mapping' since the Mandelieu proposal but I was not sure what, so I went for a long walk in the
snow, watching squirrels and prairie dogs, and I came back with the following thoughts:

Let's forget about 'mapping' for a moment and look at the global rules:

ITS is essentially about "information" that we apply to parts of documents.

When we do <its:translateRule its:selector="//p" its:translate="yes"/> we apply translate='yes' to the selection. Here the
information is discrete, predictable. And this works also for dir and term (forget termRef for the moment). No problem.

Then comes three data categories where some of the information we want to apply to our selection are not discrete, and not even
predictable: locInfo, locRef, termRef and the different parts of ruby. In these cases we have a portion of document (identified by
its:selector) that needs to be assign something that we cannot know in advance (text, URIs). It is a very different type of
information than the discrete/predictable values of translate or term.

There are two ways of providing the information:

-1 we can put it in an ITS-dedicated container: <its:locInfo>, its:locInfoRef, its:termRef, <its:rubyText>, etc.

-2 or we have the cases where the information exists already in the document and we have to provide a way for the rule to point to
it.

- first this 'pointing' does not apply to the 'data category' itself, but only to one of the pieces of information in the data
category.

- second it must be expressed as an XPath expression relative to the selector of the rule.

If I look at the discussions about 'mapping', those two aspects were in the original exchanges and it was OK. But then the idea of
generalizing this concept to all ITS information came up and this is where I got lost.

We started to talk about xml:lang, and 'mapping' semantics, etc. 'Mapping' went from expressing a pointer to some information in the
document, to expressing the equivalence between an ITS construct and a construct in the host format. 

If you go back to the original reason for the 'mapping' (truly 'pointing' or as Christian wisely noticed 'passThrough') and apply it
to its:translate, it just does not make sense: Why in the world would you want to pass through the information 'yes|no' from a
mapped attribute to <its:translateRule> where the perfectly respectable its:translate already provides these exact same values?

I'm not saying that such kind of 'mapping' is not useful, but I think it is very different from the original 'mapping' we were
thinking about with locInfoMap.

Let's call the original concept 'pointing' or 'passThrough', and the second 'mapping'.

That second concept (true 'mapping') may be useful, but I think it would require a different notation.

I would assume that such mapping means the element/attribute in the host format has the exact same semantics as the ITS information.
It other words we should be able (conceptually) to replace the host markup by the its corresponding markup. If so, there is no need
for selectors, we simply need the name of the corresponding element or attribute, nothing else. So for langMap we would have
something like:

<its:langRule its:mapName="myLang"/>

Instead of 

<its:langRule its:selector="//*" its:langMap="@myLang"/>

I would even go as far as changing this to:

<its:langMap its:mapName="myLang"/>

Since maps are very different from rules (and we want elegance...)

Maybe I'm completely missing something...
But if not, I would propose:

A) To rename these 'mapping' attributes to something closer to their true meaning (locInfoPointer? locInfoPassThrough?) and have
them only where it make sense (that is only for its:locInfo, its:locInfoRef, its:termRef, its:rubyText (what about ruby parenthesis
and complex ruby?) (did I miss any?)

B) To explore the need for mapping (true mapping) starting with its:langMap, but to do that later on, making sure we get the
its:zzzzzRules in good shape first.

Any thoughts?

Kenavo,
-yves

Received on Friday, 17 March 2006 03:08:08 UTC