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

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

From: Yves Savourel <yves@opentag.com>
Date: Wed, 15 Mar 2006 22:21:21 -0700
To: <public-i18n-its@w3.org>
Message-ID: <004d01c648b9$7732b7c0$0300a8c0@Breizh>

Hi all,

Felix, thank you for posting this summary quickly.
All: Please, make sure to look at it and comment as needed. We should be able to make a decision on this proposal during the next
regular teleconference.

My comments:

I share Felix's view on not having mapping for translate and dir.

I understand the interest of having a mapping on each data category from a conceptual viewpoint, but I think it would add
un-necessary efforts on the implementation side, while not adding any additional function since any mapping on data category
realized using a finite list of values can be done using the selection mechanism.

I see a possible reasonable boundary: We would have mapping for the cases where the information to access is not enumerable:
locInfo, locInfoRef, termRef, ruby (all the attributes needed) and language.


-----Original Message-----
From: public-i18n-its-request@w3.org [mailto:public-i18n-its-request@w3.org] On Behalf Of Felix Sasaki
Sent: Wednesday, March 15, 2006 7:45 PM
To: public-i18n-its@w3.org
Subject: Proposal: not having mapping for the translatability and the dir category


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:translateRule its:select="//xyz:bla[@xyz:translate='no']"
Sebastian's solution would be (I think)
<its:translateRule its:select="//xyz:bla"
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
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.
Received on Thursday, 16 March 2006 05:21:41 UTC

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