A possible move towards consensus? (1)

[John Clews]

Thanks for your points, Peter: they're very valid. I certainly
do not intend to add to the rather great burden there is already to
submit requests.

I am embedding some clarifications into your text:

> John Clews wrote on 05/24/2003 03:46:06 AM:
> 
> > What about splitting the full list of basic codes registrations into
> > two or three different parts? ...

In <OF57468C9B.677B1D4F-ON86256D30.0052A6AB-86256D30.005449E6 at sil.org>
Peter_Constable at sil.org writes:

> I don't have any particular objections -- I've long contended that the
> limited documentation on denotation and intended usage is a weak spot. This
> would raise some practical issues, though:

In passing, my comments were a "back of an envelope" idea.
They weren't intended to be a final solution.

> - The registrations are currently maintained as a collection of text files
> in a folder on a server, and file systems don't give you control to make
> agents viewing the directory content group the files into different parts
> and have annotation marks. This would have to be done in a single file
> documenting the total list of registrations.

Agreed. What I would envisage is a text file with basic entries for

        sr
        sr-cyrl
        sr-latn
        etc

(the complete run of tags) with cross references in the text to a URL
where more complete documentation could be found. (with asterisks, if
necessary, from any entries that want to be flagged)

If adopted, the asterisks in a text version might be converted to
links in a HTML version, if a good soul volunteered.

If not, a text version would be just fine.

The basic text document need not (and probably should not have)
a whole lot of documentation in the manner I suggested in (c)
in my original posting: that would be unnecessary extra work for the
language tag reviewer, which he is not required to do.

The HTML file at that URL would provide the additional annotation in
a separate file: perhaps somebody at W3C or ICU might offer to
maintain that, on area (c), which would document any usage guidance,
dealing with legacy uses, uses with or without script tags, etc.

> If it is needed to keep each
> registration in its individual file as well, then this
> cross-reference/annotation info would have to be duplicated into those
> individual files. This would add to the workload of the Reviewer.

Already recognised, and dealt with in the previous answer, I hope.

I don't want to add to his workload: I would like him to register the
tags recently requested though.

> - Who provides all the additional documentation you are suggesting? I
> suppose the requester, though the form specified in the RFC does not
> include this extra info, and I can easily imagine someone with a legitimate
> need making a request and being able to provide the details that are
> currently asked for, but not understanding subtleties of implementation
> issues well enough to provide the additional info you are suggesting.

No: I don't think this additional documentation should be a
requirement for submission at all, and nobody should be required to
submit it.

I was hoping that the fact that there might be somewhere
authoritative for this guidance to accumulate in due course, would
encourage the Language Tag Reviewer to hurry up and register these
codes which have been requested. If there are any problems:

(a) it's not his fault (he's raised his concerns already),
(b) it's not his problem, and
(c) somebody else will have to deal with it elsewhere
   if there are any problems

> I think it would require a commitment from the members of the list
> to being willing to work on providing this additional info when a
> request was made with an understanding that it has to be done in a
> timely manner so as not to unfairly stall a valid request, and that
> there be a time limit: if this extra info isn't forthcoming, that
> should not hold up the request.

I agree entirely. Any "type (c)" documentation would only be required
if there was a problem, ad the user community would rush to do so in
that case, as a separate exercise.

If there isn't a problem, then _nobody_ has to do any extra work.

So come on Michael - what are you waiting for? :-)

Best regards

John Clews

--
John Clews,
Keytempo Limited (Information Management),
8 Avenue Rd, Harrogate, HG2 7PG
Tel:    +44 1423 888 432
mobile: +44 7766 711 395
Email:  Scripts2 at sesame.demon.co.uk
Web:    http://www.keytempo.com

Committee Member of ISO/IEC/JTC1/SC22/WG20: Internationalization;
Committee Member of ISO/TC37/SC2/WG1: Language Codes