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

[Martin Duerst <[e-mail]>]

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