Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG

I agree.  I’m willing to work on LoST-Sync schemas but need help because my xml-fu is pretty weak.

Brian

> On Aug 25, 2021, at 5:51 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
> 
> If we go with your option:
> 
> So maybe we should normatively update 5222 to say that the RelaxNG is “replaced by” the xml schema for the purposes of defining new extensions, but the existing extension definitions in RelaxNG form are still valid.
> 
> We should probably try to also at least create an XML schema for LoST-Sync, since that's going to be increasingly needed for emergency services, at least in North America. How much would that delay the draft, or would we want to try and do it in its own document?
> 
> I'd like to hear from other group members. Especially from anyone who supports this approach and is willing to review the XML schemas.
> 
> 
> --Randall
> 
> On 24 Aug 2021, at 11:12, Brian Rosen wrote:
> 
> In general, I’d like to deprecate it, but I’m having second thoughts on the difficulty in doing so.
> 
> If we were to deprecate it, we would have to deal with existing extensions.  I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that extend LoST.  I note that all 3 of these are Experimental.   So one argument is that if we deprecate the RelaxNG schema in 5222, we have to do that to these extensions, and provide xml schemas to replace them.  I will note that LoST Sync (6739) is going to be heavily deployed soon.  
> 
> So maybe we should normatively update 5222 to say that the RelaxNG is “replaced by” the xml schema for the purposes of defining new extensions, but the existing extension definitions in RelaxNG form are still valid.  If someone wanted to help make xml schema replacements for at least 6739, that would be useful.  If we did all 3, then we probably could deprecate the RelaxNG everywhere.  This draft would have to update those 3 RFCs as well as 5222.
> 
> If we don’t deprecate the RelaxNG, then there is always the standards issue of what if there is a discrepancy between the xml schema and the RelaxNG.  I think we would have to say that it’s the RelaxNG, and we would use the errata process to fix the xml schema.
> 
> The thing to keep in mind is that every implementor I know is using xml schemas, however they get them, to build their code. The practical answer is that everyone needs xml schemas and no one needs RelaxNG.
> 
> Brian
> 
> 
>> On Aug 24, 2021, at 1:48 PM, Caron, Guy <g.caron@bell.ca <mailto:g.caron@bell.ca>> wrote:
>> 
>> Thanks for pointing me to this email. My search somehow did not find this one.
>>  
>> Reading the comments, it seems to me that the commenter is not totally adverse to the idea of making a normative change towards the XML schema.
>>  
>> I’m not familiar enough with the process to determine if or how the RelaxNG version of the LoST schema can be deprecated. I can live with a normative XML version to which any further extensions (or updates) attach to and leave the initial RelaxNG schema becoming organically outdated and useless.
>>  
>> Thanks,
>>  
>> Guy
>>  
>> De : Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> 
>> Envoyé : 23 août 2021 17:12
>> À : Caron, Guy <g.caron@bell.ca <mailto:g.caron@bell.ca>>
>> Cc : ecrit@ietf.org <mailto:ecrit@ietf.org>
>> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG
>>  
>> https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/ <https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/>
>>  
>> If we don’t deprecate the RelaxNG schema, shouldn’t extensions have to provide Relax NG?   That’s my setf serving reason to deprecate it.   I guess we could not actually deprecate it, but normatively update 5222 to say that extensions should reference the xml schema.
>>  
>> Brian
>>  
>>  
>> 
>> 
>> On Aug 23, 2021, at 4:59 PM, Caron, Guy <g.caron@bell.ca <mailto:g.caron@bell.ca>> wrote:
>>  
>> If you refer to general comments made in the early days of LoST, some 15 years ago, I guess time tells that RelaxNG did not ramp up as expected.
>>  
>> I can’t find comments on the ECRIT list specific to planned-changes asking for XML schemas to be informative while updating RFC5222.
>>  
>> I agree with your sentiment that XML schemas should be a normative alternative (i.e., does not deprecates) to RelaxNG.
>>  
>> Besides, by not providing RelaxNG equivalents for the extensions, isn’t that what you are doing anyway?
>>  
>> Thanks,
>>  
>> Guy
>>  
>> De : Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> 
>> Envoyé : 23 août 2021 16:37
>> À : Caron, Guy <g.caron@bell.ca <mailto:g.caron@bell.ca>>
>> Cc : ecrit@ietf.org <mailto:ecrit@ietf.org>
>> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG
>>  
>> We have had comments suggesting it be non normative, which is why it says what it does now. 
>>  
>> My personal view is that it should replace the Relax NG schema, and any subsequent changes and extensions should only reference this one. No one that I know uses the Relax NG schema one way or another they get an xml schema and use that. 
>>  
>> But I will go with whatever the consensus is  
>>  
>> Brian
>>  
>> On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy <g.caron@bell.ca <mailto:g.caron@bell.ca>> wrote:
>> In section 7, the replacement XML schema is qualified as an “informative alternative” however, the text in the Intro states “Alternative schemas have been circulated, which is undesirable, as they may not be in conformance to the RelaxNG schema in [RFC5222]. This document provides an XML schema that replaces the RelaxNG schema. It can be used by any implementation interchangeably with the RelaxNG schema.”
>>  
>> The latter seems to indicate that the XML schema in section 7 is a normative alternative rather than an informative one.
>>  
>> I think this is what we want but the text must be adjusted accordingly.
>>  
>> Thanks,
>>  
>> Guy
>> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
>>  
>> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>