[ESW Wiki] Update of "its0509SpecScoping" by fsasaki

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


------------------------------------------------------------------------------
  
  '''[[CL: Excellent remarks/thoughts of course. To me, this is related to the issue we usually have with 'null' values (namely that the semantics often is unknown or gets compromised. ]]'''
  
+ '''[[FS: How about having then a third value: "yes", "no", "null"? This proposal is independend of the rest of the discussion about defaults etc.''']]'''
+ 
  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>).
@@ -181, +183 @@

  The information "This is some locinfo" would apply to all kinds of locinfo.
  
  '''[[YS- But myns:para has its own purpose. How could we put loc info in it? Maybe I don't understand...]]'''
+ 
+ '''[[FS- You might want to create complex loc info, consisting of several paragraphs or lists. For that purpose, you could just use the existing elements of the schema as in the example. ''']]'''
  
  So the general way to express rules and other kinds of information:
  
@@ -228, +232 @@

  Sorry as well for not being explicit about the rationale for the changes. Here it comes: 
  
   * From my understanding, the 'translate' vs. 'translateYes&translateNo' decision is still pending
+ 
+ 
+ '''[[FS''' Sure, these are just proposals. ''']]'''
+ 
   * 'dirScope' rather than 'bidiScope' seemed to be more consistent (since I detected the naming rule x+scope)
   * 'isTerm', 'lingInfo' and the corresponding scoping attributes address some of the other requirements we
     discussed (namely term identification and linguistic markup)
@@ -238, +246 @@

  {{{ <e translate="no" translateScope="." translate="yes" translateScope="@a" a="Review">456</e>}}}
  
  Since attribute names have to be unique.
+ 
+ 
+ '''[[FS''' The problem with I see with 'translateYes&translateNo' is the combination of features and values in one name. For new values, like 'null' or 'maybe', we might need even more names: translateNull, translateMaybe, translateXYZ (I'm exaggerating). Having only one name like @translate and a possible open (and extensible) list of values seems to be better design to me. Your example could work with elements like <its:rules> which don't contain foreign markup (to avoid conflict of processing chains), e.g.
+ 
+ {{{ <e a="Review"><its:rules><its:rule translate="no" scope="@a"/><its:rule translate="yes" scope="."/></its:rules>456</e>
+ }}}
+ 
+ The interpretation of the rules should be that the XPath expression takes the parent node as the context node.
+ 
+ Nevertheless, I still see this as an addition to the simple @translate attribute. And as for the dislocated case, I think a conversion between the two would be highly desireable.
+ ''']]'''
  
  ''']]'''
  {{{

Received on Tuesday, 11 October 2005 16:19:58 UTC