[ESW Wiki] Update of "its0509SpecScoping" by MartinDürst

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 MartinDürst:
http://esw.w3.org/topic/its0509SpecScoping


------------------------------------------------------------------------------
  
   * By default, the content of all elements has to be translated and the values of all attributes do not have to be translated.
  
+ '''[[MJD: it is very important to make sure that there is a way to (re)set the default.
+ This may not be a problem for "Indicator of Translatability" ("on" is the default, and can be set),
+ but it was (and still is) a serious problem for xml:lang, where it took us several years to
+ realize that we needed something like xml:lang="" to accomodate putting data together
+ from different sources, some of which comming without language information.
+ Actually, to think of it, just having "on" and "off" for "Indicator of Translatability"
+ also seems to have some problems. The problem here isn't that we can't go back to
+ the default, but it may be (at the moment) the default itself. If we get data from
+ different sources, with what right do we claim that if there is no specific info,
+ it has to be translated? Being able to say that one just doesn't know whether or not
+ to translate seems to have a lot of value, also from a management/workflow perspective;
+ it allows to clearly identify data that hasn't yet been examined for translatability.
+ Getting that far, it would probably be best to set the default to "don't know".
+ Otherwise, data that comes in needs to be tagged as "don't know" before it can be
+ considered "not wrong". Just a thought.]]'''
+ 
  To change the default (ie. to specify what needs to be translated and what does not need to be translated), we discussed the following:
  
   * We have a {{{translate}}} attribute with a "yes|no" value. The attribute can be used at the element level, and within schema files (e.g. when defining a XSD <element>).
@@ -75, +91 @@

  However, problems may arise if full XPath (rather than only a subset) is permitted. Example: An XPath expression 'pointing' to an elements anchestors. Thus, one could consider an approach for restricted XPath.
  
  One positive aspect about XPath is of course the knowledge which people already have about it, and the libaries and other utilities which already are available for it. In addition, XPath may also be the solution to the requirement related to 'limited impact' since it not only allows for an 'in situ' assignment of ITS related properties but also for a 'dislocated' assignment.
+ 
+ '''[[MJD: How does using XPath combine with using XSLT to transform the base text without loosing
+ translatability information? Even for xml:lang, it's not trivial to come up with an XSLT that
+ preserves xml:lang. When using XPath, this may be much more complicated. However, being able
+ to carry information across XSLT transforms is highly desirable in my view.]]'''
  
  * in situ

Received on Tuesday, 11 October 2005 10:24:26 UTC