Proposal: not having mapping for the translatability and the dir category

Hi,

This is my proposal on not having mapping for the translatability and
the dir category.

- Background discussion: You might read the thread starting at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0261.html .

My arguments against @translateMap and @dirMap:

- Having mapping attributes for translatability and dir provides new
syntax, but not new functionality.

- Sebastian mentioned the use case of having ITS markup declarations in
a schema "xyz", but within the namespace of that schema. That is:
<!ELEMENT xyz:bla ...>
<!ATTLIST xyz:bla xyz:translate (yes|no) #IMPLIED>
my solution would be:
<its:translateRule its:select="//xyz:bla[@xyz:translate='yes']"
its:translate="yes"/>
<its:translateRule its:select="//xyz:bla[@xyz:translate='no']"
its:translate="no"/>
Sebastian's solution would be (I think)
<its:translateRule its:select="//xyz:bla"
its:translateMap="@xyz:translate"/>
My solution is more verbose, but
	* it fulfills the same purpose as Sebastian's
	* assuring whether s.t. is selecting relies only on the "success" of
applying XPath in the instance. With Sebastian, this assurance relies on
having the "xyz" schema available for document creation / validation. My
understanding is, that this might not always be the case, given
localization scenarios with a long chain of participants.

- Having mapping attributes for translatability and dir forces the user
to make more decisions: should I use the map attributes, the "add
information" attributes, both, ...?

- On the argument of the benefit of having the same mechanisms for all
data categories: I think this does not count, because
	* There are data categories, which need only mapping (e.g. the lang
category), there are others, which need only "adding information" (e.g.
translate), there are others, which could use both (e.g. locInfo). I
don't see a need to require only for mapping that it should be possible
for every data category.
	* Mapping and burden on implementors / users: having mapping for
translate is a burden for implementors and users. Given also the
discussion with the DITA folks, My impression is: a user / implementer
will *not* say
		a) "What (mapping, selecting, ...) mechanisms does ITS provide?", but
rather
		b) "I want to express information about a data category (e.g.
translatability): How can I do it?"
	  That is: people will not be confused by not having every mechanism at
every data category, but rather by having mechanisms without a benefit
for the data category which they want to use.

- On the argument of "clean" design of ITS (brought up by Sebastian
yesterday):
I like dirty, but useful design :)
To be serious: From a users / implementors / conformance point of view,
it seems to be likely that we will have a conformance for each data
category separately. That is: what seems to be "clean" from a
conformance perspective "having all data categories at once", is quite
"unclean" from the "just one category" perspective.

- On general importance of "mapping": I am afraid that we are loosing
our perspective. IMO it should not be "let's describe everything with
equal importance, which is possible with ITS?", but rather "let's
concentrate on core features". Mapping is not a core feature (IMO),
hence it should not have an influence on the general design of ITS. What
we did in Mandelieu (going through all possible usage scenarios for all
data categories) was very good. But it must not disturb our perspective.

Looking forward for feedback. Best regards, Felix.