ACTION-152: Find out about LSP requirements for ISO/TS 11669 values in ITS 2.0

The following email chain helps explain this matter:

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.

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

[fsasaki]: From Arle: This is still an interesting task, but I don't see it impacting ITS 2.0 at this point. So I think we can let it go. The consensus a few weeks back seemed to be that we should leave the Linport stuff alone and let Linport worry about it, even if we do keep an eye on it. So I'll send a note to the list saying that we are closing it (just so people know) and you can go ahead and close it.