Subject: RE: [Ltru] Referencing the Scheme within the Tag

From: "Addison Phillips" <[email-masked]>
Date: Sun, 3 Jul 2005 10:25:24 -0700

Huh? You mean putting a subtag into the language tag to indicate what kind (generation) of tag it is?

The 3066bis scheme represents a narrowing of the 3066 grammar for language tags. Unlike 3066, it represents a full description of every subtag, including those unassigned by 3066bis. It will not be possible to create a new, different, grammar for language tags without breaking compatibility with 3066bis. Any "3066ter" or later will essentially provide additional rules for putting things into the registry, not modify the grammar of a tag.

What will be more important to archivists will be the registry date. This will define what subtags were valid at the time. (Once we switch to a registry, the scheme itself is less important than the registry)

Putting a subtag into the tag to indicate the scheme is a colossal waste as it conveys no useful information. But I may be misunderstanding your comment, since you put the (Scheme_RFC_3066_bis) on the left side of the ABNF statement.

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Debbie Garside
> Sent: den 3 juli 2005 02:59
> To: [email-masked]
> Subject: [Ltru] Referencing the Scheme within the Tag
> 
> An issue that I still feel quite strongly about is the referencing of the
> encoding scheme within the language tag itself; I believe it is essential
> for long term archival processes.  I would like to propose the addition of
> the following:
> 
> "Implementers MAY reference this scheme within the language tag itself
> using
> the following syntax:
> 
> Language-Tag (Scheme_RFC_3066_bis) = ..." or some such...
> 
> This would be particularly useful when tagging cultural information for
> archival purposes e.g. digitalised manuscripts.  It would give archivists
> the ability to maintain, reference and update their systems.
> 
> 
> Debbie Garside
> www.linguasphere.com
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Debbie Garside" <[email-masked]>
Date: Sun, 3 Jul 2005 19:59:41 +0100

Hi Addison

See in-line comments...

> From: Addison Phillips [mailto:[email-masked]]
> Sent: 03 July 2005 18:25
> To: Debbie Garside; [email-masked]
> Subject: RE: [Ltru] Referencing the Scheme within the Tag
> 

No, I do not mean putting a subtag into the language tag.  I mean inserting
a piece of text (as proposed) that will create a mechanism for archivists to
be able to record and return "records" that match "RFC 3066 bis" in the
language tag in some far off future maintenance/update scheme.  

There is also the issue of cross-over implementation dates, from one scheme
to another (bis to ter perhaps); as we all know that implementers do not
necessarily change their systems to match new standards immediately upon
release so document date doesn't necessarily help.  But I could be waffling
a little here :-)

> The 3066bis scheme represents a narrowing of the 3066 grammar for language
> tags. Unlike 3066, it represents a full description of every subtag,
> including those unassigned by 3066bis. It will not be possible to create a
> new, different, grammar for language tags without breaking compatibility
> with 3066bis. 

I am not talking backward compatibility, I'm talking forward extensibility,
and retrieval for future maintenance and update procedures in a particular
industry.

> Any "3066ter" or later will essentially provide additional
> rules for putting things into the registry, not modify the grammar of a
> tag.

Exactly. I am assuming that language tags in the future may incorporate more
information e.g. written/spoken (something that will definitely rear its
ugly head again in the future ter methinks). If an archivist cannot
reference the scheme that has been used within the document they may have to
look at each and every tag to see which scheme has been used. This would
involve evaluating the document again to see whether the information is
absent from the tag because it is not relevant to the document or because
the scheme used at the time of encoding did not facilitate the incorporation
of said information.

> What will be more important to archivists will be the registry date. This
> will define what subtags were valid at the time. (Once we switch to a
> registry, the scheme itself is less important than the registry)

Not true (possibly :-)).  Given that the registry will, I assume (please
correct me if I am wrong) never delete a tag (deprecate etc. but not
delete), this is of no consequence.  If a subtag is within a document using
RFC 3066 bis or its successors, in theory, it SHOULD be within the registry.
(Actually, looking at it from another point of view I can see your point!
But I am assuming the registry is going to be forever changing as people
register subtags, so what date would be used? But, that is another problem.
The subtag registration date might help when analysing tags!)

> Putting a subtag into the tag to indicate the scheme is a colossal waste
> as it conveys no useful information. But I may be misunderstanding your
> comment, since you put the (Scheme_RFC_3066_bis) on the left side of the
> ABNF statement.

My proposal will allow archivists to reference the scheme used and does not
form an additional subtag.  My intention was to put it on the left of the
ABNF in order that it MAY be incorporated as a reference only if end users
needs require but does not form part of the actual language subtag. I cannot
see the harm in facilitating this; my proposal opens the door to another
industry gaining good use from this standard (can never be a bad thing when
thinking about knowledge grids).

Personally, I think it would be SMART for the MAY to be SHOULD but then I
like to have as much information available as possible; my philosophy only.
By suggesting MAY I was trying not to tie other people into using this; I
understand some users have space concerns.

Kind regards

Debbie Garside
www.linguasphere.com

---

From: r&d afrac <[email-masked]>
Date: Mon, 04 Jul 2005 02:42:25 +0200

>and retrieval for future maintenance and update procedures in a particular

Debbie,
Addison describes his intent to rule the future. No objection to that, 
except he also wants to rule the net.(BCP 47) This not possible, the net is 
not to be narrowed but scaled.

I have a question: Addison puts already too many information in his tag 
(too many, because they can have unexpected conflicts). Why do you want to 
add more? You do not have conflict in adding specialised metatags. What is 
actually the odd idea is an ABNF langtag when an XML or other open format 
could have solved all these problems much more simply?

jfc

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 4 Jul 2005 07:47:27 +0100

Hi Jefsey

I do not wish to add more information into the tag.  I just want to
reference the scheme.  The fact that the scheme MAY be updated in the future
to include additional information is part of the reason for requiring the
reference.

Kind regards

Debbie

> From: r&d afrac [mailto:[email-masked]]
> Sent: 04 July 2005 01:42
> To: Debbie Garside
> Cc: [email-masked]

---

From: r&d afrac <[email-masked]>
Date: Mon, 04 Jul 2005 10:29:22 +0200

>to include additional information is part of the reason for requiring the

Debbie,
RFC 3066 is used in a lot of places and the Draft "narrowing" changes its 
nature. It is likely that this new nature will not always be accepted, all 
the more in the new IANA context. This means that we will have several 
coexisting schemes as both the narrowing and the needs will increase. The 
result will probably be complex semantic (look at the added complexity by 
this fist narrowing level, after 18 versions: even the target is to make 
RFC 3066 ter as simple as they wanted RFC 3066 bis to be). There will be at 
least three coexisting schemes. This is why it seems much more promising to 
work on a private generalised x-tags open space along with an ISO 11179 
approach, where all this issues will have to be addressed in the context of 
the present state of the art, without having to rebuild the wheel.

The only fear I have is that ISO 11179 is complex and may very well be 
another X.500 story. This is why I wish to keep the multilingualism and the 
networking aspects under other fora (including IETF) control. So if an 
Internet vision had to emerge (like for LDAP) we could make it more easily. 
Designing it in the context of this WG could be possible (it was my request 
to ADs when I called for a WG-TAGS) but would call for far more people to 
assemble. I called for that on the IETF main list, but the chair opposed we 
had some of them on the list (but never heard about).

jfc

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 4 Jul 2005 16:18:25 +0100

JFC wrote:

> This means that we will have several
> coexisting schemes as both the narrowing and the needs will increase.

All the more reason to reference the scheme within the tag.

> > The only fear I have is that ISO 11179 is complex.

This is my view also.  I have further investigations to do on this and would
not at this stage (or possibly even at any stage) be suggesting to this WG
to adopt ISO 11179. Initial discussions with industry suggest there MAY be a
split view on its use; I don't know.  I understand that this WG has already
discussed 11179 and made the decision not to apply the standard at this
stage.  For my purposes so far, within the draft for 639-6 (and please
remember this is not yet ratified by ISO), it works quite nicely.

> assemble.

I understand that this is an anonymous list; however, it would be
interesting to know how many people are subscribed.  Randy?

Kind regards

Debbie

> Sent: 04 July 2005 09:29

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 4 Jul 2005 12:33:41 -0700

Hi -

> From: "Debbie Garside" <[email-masked]>
> To: "'r&d afrac'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, July 04, 2005 8:18 AM
...
> interesting to know how many people are subscribed.  Randy?
...

It's not anonymous, in that postings are not anonymized.
To keep spam down, the address listing isn't made available.
There are currently 57 addresses subscribed.  It's hard to know
how many different people this comes to be, since we have
a few people with multiple addresses subscribed, and I know that
some of the subscribed addresses lead to distribution lists or
news groups.

Randy, ltru co-chair