[ESW Wiki] Update of "its0505ReqNamingScheme" by YvesSavourel

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


------------------------------------------------------------------------------
  
  === Summary ===
  
+ It should be possible for translation tools to rely on a predictible list of element and attribute names for a given type of documents.
- It should be possible for translation tools to rely on a finite list of element names in a given schema. '''[[FS-''' This is a problematic requirement, because of the ANY operator. In DTDs [http://www.w3.org/TR/REC-xml/#sec-element-content],  ANY requires that all elements in the content model are declared. For XML Schema [http://www.w3.org/TR/xmlschema-0/#ref32] or RELAX NG [http://relaxng.org/compact-tutorial-20030326.html#id2816343] (in RELAX NG the respective construct is a name class '*') ANY allows any element in the content model, even if it is not declared. Actually this is a very powerful extension of what is possible with DTDs, e.g. you can combine your schema with XSLT / schematron, no matter what version, i.e. what set of XSLT elements you are using. It might be hard to convince people to give up that feature. Proposal for a reformulation: 'It should be possible for translation tools to rely on a finite list of element names in a given schema. Additional elements might be introduced to the schema, but they should have no influence on the application of the its tagset.'.''']]'''
- 
- '''[[YS-''' First I think we have to realize that many of the XML documents like with that type of element names do not even have corresponding schema. they are just well-formed. (Actually as far as I can tell there is a fair amount of XML files I see go through translation that have no corresponding schema/DTD). '''[[FS-''' That is a very good and important point! And it shows a problem we might want to address: We might have the need to use the tag set to describe documents without a schema, i.e. we cannot describe the tag set as element declarations etc. Alternatively, corresponding XPath expressions might be useful, e.g. for 'ATTLIST span loc-note CDATA #REQUIRED' is s.t. like template match='span[@loc-note]'. ''']]''' But you are right, the term 'finite' is probably not the right one. The issue is that the names are 'unpredictable', but I can't find a way to describe it. I'll think about it.''']]'''
  
  
  === Challenge/Issue ===
  
- Using documents where the elements do not follow a finite list of names may cause problem for translation tools. This is especially true if not all parts of the document are not to be translated. In that case the rules to distinguish the translatable elements from the non-translatable ones would be difficult to specify.
+ Using documents where elements or attributes do not follow a predictible naming pattern may cause problem for translation tools. This is especially true if not all parts of the document are not to be translated. In that case the rules to distinguish the translatable nodes from the non-translatable ones would be difficult to specify.
  
  For example, the following XML excerpt is not conducive to localization because the list of elements cannot be easily codified for translation rules.
  
@@ -34, +32 @@

  
  === Quick Guidelines ===
  
+ Documents should not use element or attribute names that are generated from identifiers. Instead, one should use an attribute to store the identifier:
- Documents should not use elements that are dynamically created. 
- 
- [[CL From my understanding, the dynamic creation is not the issue. It's the pattern that is used for creation that is critical.]]
- 
- Instead of using element names as identifiers, use an attribute to store the identifier:
  
  {{{<button id="OK">OK</button>
  <button id="cancel">Cancel</button>
@@ -46, +40 @@

  
  [[MI One issue we might need to consider regarding this is specifying translatability. Translation tools usually specify either an element or an attribute as translatable/non-translatable. For example, you can specify <OK> as non-translatable, while <Cancel> is translatable. But if you do as <button id="OK".. or <button id="Cancel", then you cannot just disable translatability only for OK (unless otherwise a translation tool has some conditional mechanism in specifying translatability. This naming scheme may need to be considered only when translatablility doesn't matter.]]
  
- '''[[YS-''' I'm not sure I agree: we could have <button translate="no">OK</button> and <button translate="yes">Cancel</button>. And tools should be able to make the distinction no? I think the translatability should be independant from the element name. It's true that many current tools have that problem, but I would say it's a tool problem, not an XML issue.''']]'''
+ '''[[YS-''' I'm not sure I agree: we could have <button translate="no">OK</button> and <button translate="yes">Cancel</button>. And tools should be able to make the distinction no? I think the translatability should be independant from the element name. It's true that many current tools have that problem, but I would say it's a tool problem, not an XML issue. --- Masaki, did my comment make sense? For example, the problem you described was truie in Trados-6 bur is not true in Trados-7 anymore where you can specify parts that are translatation on attribute values (hence, demonstrating that it's a tool issue).''']]'''

Received on Monday, 27 June 2005 16:00:37 UTC