RE: [Ltru] Referencing the Scheme within the Tag

["Debbie Garside" <debbie at ictmarketing.co.uk>]

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
 




> -----Original Message-----
> From: Addison Phillips [mailto:addison.phillips at quest.com]
> Sent: 03 July 2005 21:09
> To: Debbie Garside; ltru at ietf.org
> Subject: RE: [Ltru] Referencing the Scheme within the Tag
> 
> 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:debbie at ictmarketing.co.uk]
> > Sent: den 3 juli 2005 12:00
> > To: Addison Phillips; ltru at ietf.org
> > 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
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru