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

From: "Addison Phillips" <[email-masked]>
Date: Sun, 3 Jul 2005 13:08:41 -0700

Comments below, excess text deleted.

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: Debbie Garside [mailto:[email-masked]]
> Sent: den 3 juli 2005 12:00
> To: Addison Phillips; [email-masked]
> Subject: RE: [Ltru] Referencing the Scheme within the Tag
> >
> > Huh? You mean putting a subtag into the language tag to indicate what
> kind
> > (generation) of tag it is?
> 
> 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.
[Addison Phillips] 

The text you propose would be in the ABNF definition of the term "Language Tag". It is unlikely to be referenced anywhere except in the 3066bis document. Instead, references will be to the RFC or BCP number of the document.

> 
> There is also the issue of cross-over implementation dates, from one
> scheme
> to another (bis to ter perhaps); 
[Addison Phillips] 

Which don't matter: all RFC 3066 tags are also RFC 3066bis tags. The same will be true of the bis->ter transition. What will change are the entries in the registry (there will presumably be more of them).

> 
> > 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.
[Addison Phillips] 

The registry provides dates that can be referenced and the rules in bis do not allow subtags to become extinct or be reused. If a future version were to provide for such instability, then *it* should define ways for implementations to identify themselves.

What's important is: "I have a language tag" and then divining what the subtags are. 
> 
> > 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. 
[Addison Phillips] 

No, they will have to look at the subtags and refer to the registry to determine the meaning of each. Additional subtag types might come into existence, but these will be defined in some future version of the 3066 series. 3066bis implementations will only know that "I have a variant subtag" or "I have an extension subtag" or even "I have an extended language subtag", but not the given additional meaning. This is NOT bad. It is good: it means that 3066bis implementations are somewhat future proof!

The stability rules allow archivists to be confident that we won't go changing the meaning of their tags: it is a key element of the new document.

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.
[Addison Phillips] 

Okay, I see what you're saying: someone might want to retag to use new, more granular semantics (hmm... like ISO 639-6, eh?). If any equivalencies have been established, then the current 3066bis++ registry will contain the mappings that allow one to track forward. If no equivalencies have been established, then content owners will have to decide (but their tags will still convey the original meaning).
> 
> > 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!)
[Addison Phillips] 

Which is why it exists.
> 
> > 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).
[Addison Phillips] 

They should reference the parent document and not the scheme in the ABNF. That is a more reliable and complete reference anyway.
> 
> 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.
> 
Referencing the document does this. There are references to RFC 1766 that exist in the world and they communicate specific restrictions on language tags and the subtags used to form them, for example.

Best Regards,

Addison

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

---

From: "Debbie Garside" <[email-masked]>
Date: Sun, 3 Jul 2005 21:43:57 +0100

Hi Addison

> No, they will have to look at the subtags and refer to the registry to
> determine the meaning of each. Additional subtag types might come into
> existence, but these will be defined in some future version of the 3066
> series. 3066bis implementations will only know that "I have a variant
> subtag" or "I have an extension subtag" or even "I have an extended
> language subtag", but not the given additional meaning. This is NOT bad.
> It is good: it means that 3066bis implementations are somewhat future
> proof!

I agree! But matching a tag or determining what a tag means is not my point.

> The stability rules allow archivists to be confident that we won't go
> changing the meaning of their tags: it is a key element of the new
> document.

And fabulous it is I'm sure! But this was not my point either!

> Okay, I see what you're saying: someone might want to retag to use new,
> more granular semantics 

Yes! Now we are getting there!

> (hmm... like ISO 639-6, eh?). 

Well yes, if you want to look at it that way... but not just 639-6 ANY other
additions/extensions that may occur in future updates... 

What harm is there in my proposal?

Kind regards

Debbie

> From: Addison Phillips [mailto:[email-masked]]
> Sent: 03 July 2005 21:09
> To: Debbie Garside; [email-masked]
> The text you propose would be in the ABNF definition of the term "Language
> Tag". It is unlikely to be referenced anywhere except in the 3066bis
> document. Instead, references will be to the RFC or BCP number of the
> document.
> 
> >
> Which don't matter: all RFC 3066 tags are also RFC 3066bis tags. The same
> will be true of the bis->ter transition. What will change are the entries
> in the registry (there will presumably be more of them).
> 
> >
> The registry provides dates that can be referenced and the rules in bis do
> not allow subtags to become extinct or be reused. If a future version were
> to provide for such instability, then *it* should define ways for
> implementations to identify themselves.
> 
> 
> No, they will have to look at the subtags and refer to the registry to
> determine the meaning of each. Additional subtag types might come into
> existence, but these will be defined in some future version of the 3066
> series. 3066bis implementations will only know that "I have a variant
> subtag" or "I have an extension subtag" or even "I have an extended
> language subtag", but not the given additional meaning. This is NOT bad.
> It is good: it means that 3066bis implementations are somewhat future
> proof!
> 
> The stability rules allow archivists to be confident that we won't go
> changing the meaning of their tags: it is a key element of the new
> document.
> 
> 
> This would
> Okay, I see what you're saying: someone might want to retag to use new,
> more granular semantics (hmm... like ISO 639-6, eh?). If any equivalencies
> have been established, then the current 3066bis++ registry will contain
> the mappings that allow one to track forward. If no equivalencies have
> been established, then content owners will have to decide (but their tags
> will still convey the original meaning).
> >
> They should reference the parent document and not the scheme in the ABNF.
> That is a more reliable and complete reference anyway.
> >
> Referencing the document does this. There are references to RFC 1766 that
> exist in the world and they communicate specific restrictions on language
> tags and the subtags used to form them, for example.
> 
> Best Regards,
> 
> Addison

---

From: Marion Gunn <[email-masked]>
Date: Mon, 04 Jul 2005 09:19:03 +0100

Echoing DG's question (below). I see only advantage in her proposal.
mg

Scríobh Debbie Garside:
> ...
-- 

Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an 
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *