W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

Re: ITS - Example 11 of the specification

From: Felix Sasaki <fsasaki@w3.org>
Date: Tue, 24 Jan 2006 11:30:26 +0900
To: "Yves Savourel" <ysavourel@translate.com>, public-i18n-its@w3.org
Message-ID: <op.s3u2k0d2x1753t@ibm-60d333fc0ec.mag.keio.ac.jp>

Hi Yves, all,

On Tue, 24 Jan 2006 03:23:35 +0900, Yves Savourel  
<ysavourel@translate.com> wrote:

>
> Hi,
>
> I was wondering about the Example 11 (Example for using schemaRule and  
> documentRule together in a schema):
>
> ...
> <its:documentRule translate="no"  
> translateSelector="//p[@editor='john']"/>
> <!-- This rule holds for p elements which are edited by John. -->
> ...
>
> First: Also: shouldn't <documentRule> be in a <documentRules>?


yes, you are right. I'll change that.


>
> Second What does it mean exactly?
> A) That any //p[@editor='john'] in the *schema* should not be translated,
> or B) that any //p[@editor='john'] in instances of the document type  
> describe in the schema should not be translated?
>
> My understanding is that such documentRule would apply to the document  
> where it's located, therefore A), the schema.
>
> - is that correct?
>
> - if it's corect, the example is a bit confusing: it may be better to  
> use an example with a selector that point to something visible
> in the example (some comments for example(?))
>
> - As far as I know we don't have a "delivery" mechanism for documentRule  
> elements except that when within a document instance they
> applies that that document. But for stand-alone rules (in a separate  
> file) we don't define how to associate them with the documents
> (which is probably fine(?)).

These are goods point. Image you want to reuse a set of <documentRule>  
elements. Currently, the obvious way to do that is to copy them into the  
XML file you are working on. You want to reuse the rules for several  
documents. That was my intent for the schema example, so my answer to  
"Second What does it mean exactly?" would be B). But that is not useful.
I see two solutions:
1) We say "we don't define a mechanism about which XML document will be  
input to rules, and leave that to the implementation.
2) We define e.g. an @documentUri attribute for the <documentRules>  
element which contains
	a) the document URI (that is, the document location)
	b) an empty value which means "this can be applied to any document which  
is input to an ITS processor" (if we call it like this ;) )". So example  
11 would than be

<xs:schema>
  <xs:annotation>
   <xs:appinfo>
    <its:documentRules documentUri="">
     <its:documentRule translate="no"  
translateSelector="//p[@editor='john']"/>
<!-- This rule holds for p elements which are edited by John. -->
    </its:documentRules>
   </xs:appinfo>
  </xs:annotation>
...
</xs:schema>

meaning that these rules can be used for any XML document. Putting them  
into the schema is just for convinience; instead of the schema, it could  
be in a separate file as well:

<myFile>
<its:documentRules documentUri="">
     <its:documentRule translate="no"  
translateSelector="//p[@editor='john']"/>
<!-- This rule holds for p elements which are edited by John. -->
    </its:documentRules>
</myFile>

to have this worked for a set of files, we can allow multiple URIs as the  
value of @documentUri:

<its:documentRules documentUri="file1.xml http://example.com/file2.xml  
file3.xml http://example.com/file4.xml">
     <its:documentRule translate="no"  
translateSelector="//p[@editor='john']"/>
<!-- This rule holds for p elements which are edited by John. -->
    </its:documentRules>

How does that sound?
>
> Just thinking aloud...

Me too :)

Felix
Received on Tuesday, 24 January 2006 02:30:33 UTC

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