RE: [Ltru] Referencing the Scheme within the Tag

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

Hi Addison

See in-line comments...

> -----Original Message-----
> From: Addison Phillips [mailto:addison.phillips at quest.com]
> Sent: 03 July 2005 18:25
> To: Debbie Garside; 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.  

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 

> 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: ltru-bounces at lists.ietf.org [mailto:ltru-bounces at lists.ietf.org]
> On
> > Behalf Of Debbie Garside
> > Sent: den 3 juli 2005 02:59
> > To: ltru at ietf.org
> > 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
> > Ltru at lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru