clean up text on id & name, IANA, etc.

[mamund]

2.2.7.3. Link Relation Values and 'id' or 'name'

I see a problem here. It's all very well to say "If the resulting link relation type is the same as a registered relation type, the descriptor MUST not change the meaning of the IANA relation type.".

But an implementer cannot know what new relation types will be implemented in future. An application that is conformant at the time of implementation may be rendered non-conformant by subsequent IANA registrations. I think this is not consistent with progressing the notion of "software engineering on the scale of decades" which I'm guessing is a motivation for this work.

One possible approach might be to require any non-registered value to be a URI or URI reference, and introduce a distinguishable prefix for local ids. (e.g. use fragment syntax such as '#idvalue' or a common URN prefix such as 'urn:ietf:alps:id:idvalue'. I'm not suggesting these as specific solutions as I don't yet understand enough of the scope of what you're proposing, just as examples of alternative approaches to contemplate.)

/via Graham Klyne

[fosrias]

@mamund Hm. Seems we need to be a little careful here not to end up with HAL curie issues in relation types in APIs and how things map. Nice to be able to map human semantics for transitions without having to use urns, etc.

Might be able to have a formal definition and use something with "name" to allow mapping on that level if there is a profile and a match. Technically, the relation type would be the urn one. Make any sense?

[mamund]

i want to make sure authors don't attempt to redefine the intent/meaning of existing rel values. and i'd like to do that w/ a minimum of hassle ;)

there are a couple things to consider:

• reg'd where (IANA, microformats, RDF ontology, etc.)
• reg'd when (Graham's point, i think) maybe when i created the profile this was not a reg'd word, but two years later is now is What is to be done?

yes, i'd like to make sure we don't create a HAL vortex ;) and i still want to come up w/ a clean solution.

sadly, namespaces come to mind ;< RFC5988-style URIs solve that problem, right?

[fosrias]

sadly, namespaces come to mind ;< RFC5988-style URIs solve that problem, right?

Sadly indeed. That is the easy way out but maybe the only? At least from a descriptor id standpoint. I will mull this one.

[smizell]

While this problem exists in the ALPS document itself, does it also exist in media types that support IANA and other link relations? In other words, if you solve name collisions in ALPS, it seems like there will still be name collisions in the message itself.

For example, say a media type supports IANA link relations but does not handle collisions. As soon as I introduce a profile into my message, I have the same problem.

Can this problem be solved if not addressed at the message level as well?

[mamund]

i think we need to be clear on the problem here. what i'd like to prevent is overriding the intent of registered link relation values. IOW, i don't want ppl to think they can use an existing rel value and apply a new meaning to it. that's a social thing, not a technical thing.

but we can use some technical details in our spec to lead ppl into behaving as we are hoping.

i think the right approach is to provide guidance on this topic ("don't change the meaning of existing LRVs) and create a MUST/SHOULD constraint that makes this behavior easy to identify/manage. something like Klyne's "use a 5988-style URI, use a URN space, use a fragid" -- these are all ways to lead ppl into behaving the way we wish.

i think we provide 1) MUST NOT redefine guidance, and 2) SHOULD use 5988-style guidance for any "invented" rel values. open to discussion there.

finally, i don't want to try to boil the ocean here -- i don't think we can solve this for ALL media types. but we can, with our mapping documents (i pub'd an HTML sample here:http://alps.io/spec/alps-to-html/), we can give guidance on this issue, too.

[fosrias]

So, first off, saying you have to use custom link relations via URIs in a message with ALPS really starts to obscure the semantics aspect IMO. Where are the semantics the custom rel? The fragment? If so, we would have to state that probably. The ability to use like semantics in a message to the id or name is something I think is a benefit.

I think given the timing issue of when defined, we can observe the spirit of not redefining links by saying if ALPS is present and defines a link it is authoritative. I overrides IANA. That way if something registered, you don't have to change things.

I think then we say ALPS MUST NOT change existing IANA definitions and call it a day. We can support custom link relation types if people are paranoid and want to clarify in the future by using a fragement URL to the descriptor.

But being able to have something like:

{
  "_links": {
    "lock": {"href": "..."}
  }
}

is something I think we should find a way to preserve in the way ALPS defines custom relation types and its mapping rules into media types.

Thoughts?

[mamund]

@fosrias

first, using 5988 URLs for LinkRel Values doesn't obscure anything. Humans might find them unpleasant, but that's all. machines don't care about the contents of the string as long as it is consistent.

Where are the semantics the custom rel?

they are in the same place as the semantics in your example for "locks" -- or any other non-registrered magic string.

if people are paranoid and want to clarify in the future by using a fragement URL to the descriptor.

let's not confuse using fragments, w/ using rel values.

if ALPS is present and defines a link it is authoritative.

love to hear more about this. explain "defines it" and i think we're ok. for example, if you want to using naked strings instead of 5988 URLs, declare a registry value (e.g. microformats, etc.). if you like, we can propose an ALPS reigstry for LinkRel values, too,

the external comment warned against having registered values showing up after the ALPS document "mints" new LinkRel values. this is a real problem we should acknowledge and, IMO, address. I'd be happy to hear arguments that say we SHOULD NOT address it.