- From: Annette Greiner via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jan 2022 19:27:32 +0000
- To: public-dxwg-wg@w3.org
My understanding of accessURL has been that it is not specifically a landing page. It is the URL to which one would direct a user wanting to access a distribution. It may be a downloadable file, and it may be a landing page, and it may be an API endpoint. The latter is explicitly mentioned in the definition, so I don't think it was ever intended to be limited to landing pages. The fact that a downloadURL isn't listed among the examples doesn't inherently exclude it, though I can see that the wording of the note is ambiguous, as @aisaac pointed out. Rather than change the meaning for what is in a sense the most fundamental property of a distribution on the web, I'd suggest we just clarify. As for the functionality that @smrgeoinfo wisely asks for, you can determine that an accessURL is a download page if it matches downloadURL. You can determine that it is an API if it matches the endpointURL of the given accessService. An app that requires machine actionable data would not be able to do anything with an accessURL that isn't for a download or an API endpoint anyway, so wouldn't it just look for downloadURLs and endpointURLs to begin with? Moreover, making accessURL something that may or may not contain data doesn't make it any easier to determine the type of the resource. It becomes one of at least three properties that need to be analyzed before use, might disagree with each other, and might all be left blank for the wrong reason. Keeping the broader definition and requiring accessURL also gets around the problem of having no good facility for requiring "one of" that @kcoyle noted. -- GitHub Notification of comment by agreiner Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1437#issuecomment-1015758241 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 January 2022 19:27:34 UTC