Re: [Ltru] Re: Remove extlang from ABNF?

["Mark Davis" <[e-mail]>]

I agree with Peter that it'd be better to remove extlang. However, I think
we can also live with option #2: leave the extlang in the ABNF, but in
normative text make it absolutely clear that that part of the ABNF is
OBSOLETE; no valid tag will ever have extlangs. That makes the people who
want stability of the ABNF (no matter how that relates to valid tags) happy,
while allowing the rest of us to remove extlang from our code and APIs.

Mark

On Dec 10, 2007 11:48 PM, Martin Duerst <[e-mail]> wrote:

> At 01:16 07/12/07, Peter Constable wrote:
> >Content-Language: en-US
> >Content-Type: text/plain; charset="utf-8"
> >
> >> From: Doug Ewell [mailto:[e-mail]]
> >
> >> >> That's my whole point - the danger that specs writers might look at
> >> >> the dropped extlang and say "they are dropping features between
> >> >> versions of  BCP 47, so we better refer to an RFC *only* and even
> >> >> leave 'or its successor' out".
> >> >
> >> > But this is a key: we are *not* dropping any features. We are
> >> dropping
> >> > the possibility of a future feature. The change to the ABNF (whether
> >> > by removing the extlang subtag entirely or by renaming and/or
> >> > comments) is to clean it up so that implementers do not implement for
> >> > non-and-never-to-be-features.
> >>
> >> I think what Felix meant was not that we are dropping features, but
> >> that
> >> it may appear to the outside observer that we are dropping features.
> >
> >I understood that. But I think it's significant that we are *not*
> removing
> >any features, and it seems to me that could be explained easily enough.
>
> [chairs hat OFF]
>
> It looks like this could be explained easily enough, but I'm quite
> sure that this won't be the case. XML, and XML Schema, are very
> strictly defined languages. Fortunately, we managed to get XML
> away from including a grammar for language tags in an early erratum/
> corrigendum. But if XML Schema has indeed used RFC 4646 for defining
> the syntactic range of language tags, then we should not remove
> some productions. It is clear to us as well as to them that there
> cannot be any valid language tags of the form ab-cde-fgh. But
> these tags, in RFC 4646 and therefore in XML Schema version foo,
> are well-formed. If they change to be non-wellformed in a new
> version of XML Schema, that essentially means that there are
> potentially some documents that conform to a schema in one
> version of XML Schema, but not in a newer one. Even if these
> language tags have not been valid, and don't make sense, that's
> a very bad idea. As an extreme example, such a tag may by accident
> be part of a document used for managing a nuclear plant. With
> a software update, the document could suddently become non-conforming,
> triggering some error.
>
> Peter, I recommend that you talk to some XML Schema folks inside
> Microsoft to understand some of their thinking. I'm sure Felix
> can provide some points of reference if needed.
>
> As for implementation effort, I agree that leaving the extlang
> production in increases implementation effort. But quite a bit
> of it can be saved by knowing that these aren't really used anymore
> (i.e. implementations only have to do the parsing for them,
> they don't have to provide any additional functionality).
> Also, we already have a long list of tests and some regular
> expressions out there which cover extlangs, which both can help
> implementers.
>
> Regards,    Martin.
>
> >The only real stability concern is that some existing parsers would
> >recognize certain hypothetical tags they might encounter as being well
> >formed when in fact they are not well formed. What possible malicious
> >effect could this have? Is this a tag in a query statement? It very
> likely
> >won't match any content. Is this a tag attributed to content? There
> likely
> >won't be any requests for it. Only in some closed system in which
> somebody
> >decided to use proprietary extlang subtags are both going to exist by
> >design. If the parser is encountering a tag somehow constructed such that
> >it has a not-by-design extlang, it won't be catching an condition that
> >could be considered an error, but the error will still be reflected in a
> >failure to match anything, and the essential fix must be in the process
> >*constructing* that tag rather than in the parser.
> >
> >
> >Peter
> >_______________________________________________
> >Ltru mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/ltru
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]
>
>
>
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ltru
>



-- 
Mark

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