Re: [all] readiness and translation process parameters

Guys

I'm trying to assimilate this before our call at 14:00 in hope of giving 
some meaningful feedback.

Phil.





From:   Arle Lommel <arle.lommel@dfki.de>
To:     Dave Lewis <dave.lewis@cs.tcd.ie>, 
Cc:     public-multilingualweb-lt@w3.org
Date:   05/07/2012 12:14
Subject:        Re: [all] readiness and translation process parameters



Hi Dave,

We have discussed specifying recommended values (via Linport), and we may 
yet do so, but there is no specific timeframe for this.

What we keep running into (both in Linport and ISO) with this task, as 
with "domain" in our project, is that there is no single ontology for the 
permissible values. While some of the items (like source language) have 
obvious, enumeratable values (BCP47 in this case), overall we do not 
believe we can enumerate the values.

I'm not sure we can specify interoperability tests at this point. What we 
could do is specify that user agents present the values in an appropriate 
form. For machine-processible results we will have to wait (and I'm 
convinced that there will only be limited interoperability possible at 
best).

I am not sure we will get the kind of LSP feedback we would like, but I 
can try to make some inquiries via Linport and GALA. It may take a while 
to get much of a response, however.

I've gone ahead and created an action for this: 
https://www.w3.org/International/multilingualweb/lt/track/actions/152

I recognize that Felix won't want us to spend a lot of time on this for 
the moment, but I think this action will help us gauge interest in this 
topic in general and decide whether to invest more time for ITS 2.0 or to 
simply leave it for Linport. (I'm agnostic on this question at the 
moment.)

Hope that helps,

Arle

On Jul 5, 2012, at 13:01 , Dave Lewis wrote:

Hi Arle,
Thanks for that summary - the http://ttt.org/specs/ site is very helpful.

However, you confirm my impression from this that OSI TS/11669 isn't 
defining permissable values for these, which limits the degree we can 
specify interoperability tests against these values.

Are there plans for ISO to populate these values at some time, or are 
there any industry groups or plans at LINPORT to publish any best practice 
values for these attributes?

Again it would be good to hear from the LSPs and clients on their interest 
in this spec so we can reach a decision on what level we can refer to 
these in either ITS2.0 or use them in test suites?

cheers,
dave

On 04/07/2012 13:43, Arle Lommel wrote: 
Hi Dave, 

The translation parameters are defined in ISO TS/11669, which was just 
published as an ISO technical specification. So those parameters are 
normative (at least if they apply to a task). Implementation is still a 
bit thin since the Technical Specification was only published a few weeks 
ago. However, they are the parameters that go into Linport, so there is 
increasing traction via Linport.

The fact that the parameter descriptions were published by ISO as part of 
TS/11669 (which has strict copyright restrictions and is sold), access 
would be a problem. But in this case Alan Melby negotiated an exception to 
general ISO copyright policy to allow the parameters only (not the rest of 
the Technical Specification) to be published openly. The URL is:

http://ttt.org/specs/

Right now these are not easily retrieved in a usable form (i.e., there 
should be a unique URI that retrieves the details for each parameter and 
nothing else, rather than the HTML page that is there now), but I can 
actually take care of that directly if I know what should be retrieved 
from a URI (e.g., the name, description, etc.) since I have access to the 
server to make these changes. Ideally, however, these would be referred to 
via ISOCat rather than from Alan's server, so I can see about how to add 
them to ISOCat (in which case the issue of access becomes part of the 
broader question of best practice for referring to ISOCat).

Note that you would still need name-value pairs at some level (although 
you might instead point to a URI with a full set of specifications 
[specifications = parameters + values]). So for the present, the reference 
to the URI would only give you the definition of the category, but not its 
value. So I would envision something more like this:

<its:rules
  xmlns:its="http://www.w3.org/2005/11/its"  version="2.0">
 <its:transParam selector="/html/body" transParamRef="
http://www.ex.com/register.txt" transParamValue="formal"/>
</its:rules>
Not sure on that particular syntax, but it should get the idea across.

Note that ISO TS/11669 also does not define permissible values: Its 
categories were intended for human consumption, so if we want 
machine-processing interoperability, we would sill need a way to point to 
the permissible values in a given scenario. So the problem is only removed 
by a step, but we gain in this scenario in that we don't need to replicate 
anything in ISO TS/11669 and we open up whatever power is available from 
TS/11669.

Best,

-Arle

On Jul 4, 2012, at 14:08 , Dave Lewis wrote:

Hi Arle,
I agree, leaving this to Linport and ISO was the broad intent of that 
transParam proposal - they are the right people to do this.

Further, I agree a dumb pointer to an external doc would be a reasonable 
alternative to name-value pairs - what do the LSP and client people think? 
Is this something people would be interested in implementing?

As with the earlier transParam suggestion, this is soft on conformance, 
but a bit more specific in referring to Linport/ISO to solve this. But 
like the standoff provenance and PROV WG discussion, the maturity of this 
external work is a factor. Could you say a bit more about this normative 
status you mention? Can the documents be made available to the WG?

I guess it would look like
<its:rules
  xmlns:its="http://www.w3.org/2005/11/its"  version="2.0">
 <its:transParam selector="/html/body" transParamRef="
http://www.ex.com/transParam.txt"/>
</its:rules>
cheers,
Dave




************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.

www.vistatec.com
************************************************************