W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

Re: [dxwg] Consider use of adms:identifier instead of prof:token (#453)

From: aisaac via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Sep 2019 08:28:47 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-532579403-1568795326-sysbot+gh@w3.org>
@agreiner I understand the concern, but the name of the name of the property does not include "prefered", it is only in the definition where (now) it is said it is for when the URI can't be used. https://w3c.github.io/dxwg/prof/#Property:hasToken

Note that in fact for me the token can be useful in other circumstances than Conneg, and it's good that the spec would leave it also open a bit, when something can be used. 

_(and now maybe I'm going to wild, I will not be offended if someone declares this completely off-scope)_ 

For example tokens could be very useful in human-readable doc, to control how one mentions a profile there. It would be good if what people use in documents can be said to be an identifier, too, albeit within the scope of a (set of) document. And it's even better they use the same string as the one that's use in Conneg. This is the sort of trick that helps developers a lot when they implement something, isn't it?

There are certainly some risks, but in fact I believe the property as it is defined actually offers more benefits than risks with respect to controlling the proliferation of "identifiers" across the board. I.e. I believe the situation would be worse without the property as it stands.

And I have read the arguments about the lack of central authority/registry. So again yes there's a risk, but at least the properties allows the creator of the profile (if they're in control of the PROF metadata served at the URI for the profile) to have a authoritative say in how they prefer things to be done.

-- 
GitHub Notification of comment by aisaac
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/453#issuecomment-532579403 using your GitHub account
Received on Wednesday, 18 September 2019 08:28:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:57 UTC