W3C home > Mailing lists > Public > public-i18n-its@w3.org > October to December 2005

[ESW Wiki] Update of "its0509SpecScoping" by fsasaki

From: <w3t-archive+esw-wiki@w3.org>
Date: Tue, 11 Oct 2005 23:22:46 -0000
To: w3t-archive+esw-wiki@w3.org
Message-ID: <20051011232246.24125.60728@localhost.localdomain>
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.

The following page has been changed by fsasaki:

  '''[[CL''' I see that the combination of features and values is problematic. I guess a slightly different angle on the issue may help us to come up with the solution we need.
  The 'translate="yes|no"' approach assumes that we are looking at a single data category. The 'translateYes&translateNo approach assumes that we are looking at two different data categories. 
+ '''[[FS''' I would say that it is one data category which is filled with two data sets (at least) - the two boolean values. Consider e.g. locinfo as a data category: it also might need a default (the locinfo you want to give for the whole document), but this could be overriden in the same way you described for the translation case. So in the case of lofinco, the data set would be a string value, which cannot be integrated into a single or several data categories. The same is true for all kinds of data categories: xml:lang, bidi (example: bidi default, default overriden for an attribute and differently for an element.).  Another point: how would you set back the default (see Martin's comment) back of translatability of you have translateYes and translateNo? with @translate, you could say translate="default". Again, the same is true for xml:lang, bidi etc. I think our solution for scope should not be narrowed to the translatability topic, but be applicable for all the other cases. But I don't know an answer to this requirement yet. To be able to move forward, I would propose: Let's have translateYes and translateNo in the working draft, and see if we get feedback from the rest of the world about a more general solution.''']]'''
  To me the approach which is based on two data categories seems more natural. It reminds me of XSD, where we have separate data categories for defaults (namely 'elementFormDefault' and 'attributeFormDefault'. It also reminds me of my own drawers: one where I put things which I need to do, and one where I put things which I do not need to do (aside: that drawer is my recycle bin :-))
Received on Wednesday, 12 October 2005 09:06:38 UTC

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