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

[Dan Banks <[e-mail]>]

Comments inline (some snipping, also) below :

On Sep 13, 2023, at 6:21 PM, Dan Banks <dbanks=[e-mail]<mailto: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.

Well, not all extensions incorporate the LoST schema itself.  I think maybe something like: "It is RECOMMENDED that future extensions be specified using XML schemas rather than RelaxNG, and MAY incorporate either this schema or the RFC 5222 version by reference as needed."

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?

Yes, I think changing the titles in section 6 and section 10 would fix this issue (along with the text changes discussed above).


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.


Right, this is noted as a verified erratum in 5222, so I believe this is the correct thing to do.


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?

Looking at this again, no, I think it is going to be more complicated than that.  At the very least, there is additional cleanup needed.  The attributeGroup name needs to not be "anyElement" as that's confusing.  In some places, following the extensionPoint group with a corresponding attributeGroup would work, I think.  But in other places, like the commonRequestPattern, the extensionPoint group appears in a sequence.  That's fine, except I do not believe you can put an attributeGroup into a sequence.  So in that case, everywhere the commonRequestPattern is used (and commonResponsePattern) you'd need to work your way back up to the complexType that contains it and put the attributeGroup there.  Also, the "notLost" group appears to allow elements in the local namespace, when I believe the intent of the original schema was to exclude the local namespace.  I believe this is reflected in the RFC 5222 appendix A version of the schema, but the compact (normative) form looks like it has a typo: notLost = element * - (ns1:* | ns1:*) { anyElement }.  That alternative is nonsensical, and I believe it should have been (ns1:* | local:*).  So this all presents a bit of a dilemma.

The easiest thing to do might be to just explicitly write an xs:any and xs:anyAttribute in every complexType where we want an extension point, which is closer to what we see in RFC 5985's HELD schema.  Either way, we probably could use additional eyes on this issue in particular.


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.


Actually, the "expires" in the 5222 schema is an attributeGroup, so I don't think you can reference that as the definition for an element.  You will need to redefine it (which I think you should do anyway), or use an attribute instead.  If you do want to reference something, then you can't also declare a type.  For "asOf", I believe you want a name="asOf", not a ref.


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.


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.

I don't understand the argument here.  Using U-NAPTR with the LoST server's app string but a new service tag is entirely independent of the usage in 5222 and gives *exactly* what you would need to find the interface in question - no guesswork and no limitations.

Dan Banks