Re: [Ecrit] Does anyone support Planned-Changed?

[Brian Rosen <[e-mail]>]

I apologize, I was unaware you were using the RelaxNG schema, and must have misunderstood what you told me some time ago.  I still maintain it’s very difficulty for the implementors to use and all the others I have talked to about this really wanted an XML schema.

Inline for more

> On Sep 13, 2023, at 6:21 PM, Dan Banks <dbanks=[e-mail]> wrote:
> 
> Well, I have been using the RelaxNG schema since the beginning of my involvement with LoST, and pretty much exclusively so.  I even used RelaxNG to define the extensions that I contributed to NENA years ago.  So I must dispute the notion that no one uses it.
>  
> I do not agree that extensions need to be maintained in the same schema language (or in multiple languages), and I’ll point out that the location used in every findService request is included by way of an extension point and both civic and geodetic location schemas are defined by traditional XML schemas (RFC 5139 for civic, OGC 06-142r1 for geodetic) rather than RelaxNG.
So, ignoring your reservations on the whole thing, if instead of: 
Future extensions to LoST are expected to use this schema as the base for the extensions, rather than the Relax NG schema
Would you be okay with:
It is RECOMMENDED that future extensions be specified with XML schemas using this schema as the base, but MAY specify a RelaxNG schema using the original in RFC5222 as the base.

>  
> As I have expressed previously, I prefer that we NOT make the new xsd for LoST normative and that we avoid calling it a replacement.  I believe it should only be a non-normative alternative like we find in Appendix A of RFC 5222.
I don’t think we say “normative”.  If I change the section title to “Alternative XML Schema” would that be acceptable?

>  
> I also believe that while point-in-time validation by a LoST server could be theoretically useful, in practice it would introduce substantial complication (to the GIS, the LoST server, and the LIS) while providing very little benefit.  It has been my experience that the quality and completeness of the underlying GIS data NOW is a far greater concern than the possibility (or even inevitability) that some portion will become invalid at a known time in the future.  For these reasons, I have not expressed support for this draft.
Noted.  Others have found it to be valuable
>  
> At this point, it is my preference that this draft be allowed to expire and that the complete and similar location draft be updated to remove all references to planned changes and be moved forward on its own.  However, I have done a limited review of the -09 version and if it continues to be worked on, there are several issues that I see:
>  
> The exceptionContainer defined on page 12 does not include the <SRSinvalid> element as a choice, but it should.
I note that this is also true of the RelaxNG schema in 5222.  I have added it anyway.
>  
> There is a group and an attributeGroup both named “anyElement” that are defined but unused.  It is unclear if these were intended to be used to define extension points.  I believe the original LoST schema intended to allow attributes of any namespace at every extension point, and I think the xsd needs an attributeGroup at every occurrence of the extension point to accomplish that.  However, it is not clear to me if the original definition in compact form correctly expresses this.  Note that the non-normative version in 5222 Appendix A does seem to include attributes of any name at the extension point.
If I just add the attributeGroup at every instance of the ExtensionPoint, does that fix it?
>  
> Section 5 identifies the new expires element with single quotes, and says it takes the form of the ‘expires’ attribute pattern from 5222 (includes tokens) but the schema includes type=”xs:dateTime”.  This doesn’t work with ref, but the ref doesn’t work because expires doesn’t exist in the target namespace.  asOf is broken similarly.
Okay, but my lack of XML expertise is showing here.  How do I fix this (make a reference to the expires definition?  AsOf doesn’t need No-Expiration, so it can use dateTime. 
>  
> Further, the expiration pertains most specifically to the validation portion of the response.  I believe it would be less confusing to declare an attribute of a different name (such as ‘validUntil’) and place this directly into the <locationValidation> element rather than the <findServiceResponse>.
I do understand but would prefer to leave it as it is.  I can make this change if others think it’s really better.

>  
> Section 5 also makes reference to “coordinate changes”, and this is problematic given that validation only pertains to civic location.  And presumably, the exemplar use case of annexation would not involve any coordinate changes.  Nor would coordinate changes of a GIS feature by themselves necessarily impact the validation portion of the response.  This line should say something else.
Haha, I meant bring things into a alignment with each other, not geospatial lat/lon.  I will change to “synchronize changes"
>  
> The draft defines a new interface to poll for changes, but provides no new mechanism for discovery.  Presumably this would work by modifying the URI discovered via U-NAPTR in some way, but first, this is not explained.  Second, I am strongly opposed to mixing XML with a Rest/JSON interface at the same endpoint (even with a different http route).  Third, I do not believe that a service to provide a list of changes should be implemented within the same piece of software as a LoST server, although that is clearly an implementation decision.  However, lack of independent discovery of such a service would effectively require the use of a reverse proxy or similar mechanism in order to allow separate implementations.  Instead, if such a service is to exist, it should be independently discoverable using U-NAPTR using the name (application unique string) of the LoST server that provided validation as input along with a new service tag.  Then implementers can build the services however they wish.
The problem with “use the name of the LoST server that provided validation as input along with a new service tag is that 5222 expressly says “Note that the HTTP URL can be any valid HTTP URL, including those containing path elements.”  I’m inclined to just say that the path determined in LoST UNAPTR resolution replaces “localhost” in the OpenAPI definition.

>  
> Section 9 includes text related to the server sending an HTTP request back to the client, which is functionality that is no longer included in the draft.  This affects a substantial portion of section 9.
Yeah, I will have to rewrite that

>  
> Finally, the introduction refers to RFC 4119.  It would be more appropriate to refer to RFC 5139.
Will do


>  
> Dan Banks
>  
>  
> From: Ecrit <[e-mail]> On Behalf Of Brian Rosen
> Sent: Friday, September 8, 2023 1:12 PM
> To: [e-mail]
> Cc: ECRIT <[e-mail]>
> Subject: Re: [Ecrit] Does anyone support Planned-Changed?
>  
> I will expand LIS, and change entry points to end points.  I’ll add the reference to Section 8.  
>  
> WRT to the XML schema:  we now have quite a bit of deployment experience with LoST.  No one (and I mean NO ONE) uses the RelaxNG schema.  They use an xml schema, normally one that NENA created because no one in NENA had ever used RelaxNG.
> I based the schema in the draft on the NENA schema.
>  
> I would be very happy to obsolete the RelaxNG schema and replace it with the XML Schema.  That would avoid the necessity to maintain both in future extensions.  That would mean that this draft updates a few other RFCs that have LoST RelaxNG schemas.
>  
> We did have discussions long ago about where to make the change to XML Schemas, and this was the draft we decided to do it in.  I would not want to split the draft at this point.
>  
> I did engage an expert (Peter Saint Andre)  to verify that the XML Schema matched the RelaxNG schema.  He helped me fix several errors I made.  I’m pretty confident they are the same, but there is no tool that could validate it.
>  
> Brian
> 
> 
> On Sep 8, 2023, at 10:24 AM, [e-mail] <mailto:[e-mail]> wrote:
>  
> Resending
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> 
> Sent: Freitag, 8. September 2023 14:55
> To: 'Randall Gellens' <[e-mail] <mailto:[e-mail]>>; 'ECRIT' <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [Ecrit] Does anyone support Planned-Changed?
>  
> Hi Randy,
>  
> I have read the document and I believe it is a useful and important extension. 
>  
> Here are my high-level comments. 
>  
> 1. On the editorial side, please expand LIS when first used.
>  
> 2. Section 3 talks about "entry points" in context of the new RESTful APIs. The correct terminolgy would, however, be "endpoints". The description of the API in that section is incomplete. A reference to section 8 would be appropriate, which uses the OpenAPI functionality (which I am not familiar with).
>  
> 3. The more substantive comment concerns the introduction of the XML schema for LoST. Since the title does not indicate the presence of this description in the document it is a bit surprising. I was wondering why you didn't just produce a new draft that contains the XML schema where the title clearly indicates it. 
>  
> There is one annoying consequence: if you introduce two schema languages for LoST, namely RelaxNG and the XML schema, then every extension going forward should actually specify the extension in both schema languages to deal with the installed base. 
>  
> FWIW I have not checked the XML schema against the Relax NG schema and validated the examples against this new schema. I hope Brian did it. It would be unfortunate if the newly proposed XML schema is not in sync with the previously published functionalty or even buggy.
>  
> Ciao
> Hannes
>  
>  
>  
> From: Ecrit <[e-mail] <mailto:[e-mail]>> On Behalf Of Randall Gellens
> Sent: Mittwoch, 30. August 2023 18:39
> To: ECRIT <[e-mail] <mailto:[e-mail]>>
> Subject: [Ecrit] Does anyone support Planned-Changed?
>  
> Members of IETF ECRIT WG:
> The two-week IETF WG Last Call on the Planned Changes drat closes TODAY. Supposedly, this is a document that NENA i3 needs and has been waiting on.
> To date the IETF ECRIT mailing list has received exactly ZERO comments on the draft during this WG last call. The logical conclusion is that no one cares about the draft and it should die. Is that accurate? Or is it just that everyone is still on August break/doldrums? I need to know.
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-ecrit-lost-planned-changes-08.html
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ecrit-lost-planned-changes-08
> --Randall
> _______________________________________________
> Ecrit mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ecrit