[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


------------------------------------------------------------------------------
  ''']END-FS]]'''
  
  '''[[YS-''' It seems maybe too generalized. ruby and translatibility are very different things. Using XPath to point to elements that are ruby seems rather strange (not to mention very complicated to process): why in the world would someone want to put that info anywhere else than in the actual element? I could see {{{its:ruby="yes"}}}, but using XPath would make things a bit confusing (you could point to an attribute for example, but an attribute could not have rb/rt info), also what about cascading/inheritence effects: they would be different for ruby abd translateYes?''']]'''
+ 
+ '''[[FS-''' Ruby is an example of a requirement which might not need scope, but maybe it needs scope (see CL comment below). Translatability has cases where one needs scope, and others where you want to rely on an default. So how about this as a general pattern for ITS declarations:
+ 
+ {{{
+ translatability = attribute translate { "yes" | "no" }?, attribute translateScope { scope }?
+ locinfo = attribute locinfo? { "yes" }, attribute locinfoScope { scope }?
+ ruby = attribute its:ruby { yes }?, attribute rubyScope { scope }?
+ bidi = attribute dir { "lr" | "rl" }?, attribute bidiScope { scope }?
+ ...
+ scope = (here we would have an XPath subset, borrowed from XSLT 2.0)
+ itstagset = (translatabiliy, locinfo, ruby, bidi, scope)
+ }}}
+ 
+ Now everybody can decide whether he wants scope or not. If not, you just don't use the scope attributes. They have different names, but are created from the same source. The example above is in RELAX NG, its counterpart as an XML DTD looks like this:
+ ''']]'''
+ 
+ {{{
+ <!ENTITY % scope
+ "CDATA">
+ <!ENTITY % itstagset 
+ "translate (yes | no) #IMPLIED
+ translateScope  %scope; #IMPLIED
+ locinfo (yes)  #IMPLIED
+ locinfoScope %scope; #IMPLIED
+ ruby (yes)  #IMPLIED
+ rubyScope  %scope; #IMPLIED
+ dir CDATA #IMPLIED
+ bidiScope  %scope; #IMPLIED"
+ >
+ 
+ <!-- In the DTD version, scope is only CDATA. But we can have a description that this should contain a subset of XPath 2.0-->
+ 
+ <!ELEMENT myElement (#PCDATA)>
+ <!ATTLIST myElement %itstagset; >
+ }}}
+ 
+ You could realize the example from Yves without introducing element names:
+ 
+ {{{
+ <its:rules> 
+   <its:rule scope="\\para" translate="no"/>
+ 
+ Could be
+ 
+ <myns:myElment translate="no" translateScope="//para">
+ ...
+ </myns:myElement>
+ }}}
+ 
+ Other rules on translation must be at different elements. But that doesn't matter: the external rules from Yves can be created by a simple xslt stylesheet which collects all translate and other its attributes.
+ ''']]'''
  
  '''[[CL-''' I might take a shot at two of the questions ...

Received on Saturday, 8 October 2005 09:09:01 UTC