An idea for URL Fragments

[sheavalentine-mdsol]

So, if a service is serving a Hale document, and a client requests a fragment, there is a sound and consistent way we could handle that (or that the client could handle it).
If an attribute matches the first part (divided by slashes) of a fragment it gets the attribute:

"_links" {"self": {"href": "http://some.hale.doc/resource"}},
"attr1": "foo"
"attr2": {"sub1": "ninja", "sub2": "cow"}
"_embedded": {"items": [{"_links": {"self": {"href": "some.hale.doc/resource/id1"}}}]}
}

http://some.hale.doc/resource#attr1 returns

"foo"

http://some.hale.doc/resource#attr2 returns

{"sub1": "ninja", "sub2": "cow"}

You can also subselect http://some.hale.doc/resource#attr2/sub1

"ninja"

If no attribute matches, check embedded: http://some.hale.doc/resource#items

 [{"_links": {"self": {"href": "some.hale.doc/resource/id1"}}}]

otherwise try and match a link http://some.hale.doc/resource#self

{"href": "http://some.hale.doc/resource"}

and again you can subselect http://some.hale.doc/resource#self/href

"http://some.hale.doc/resource"

(Obviously this is just some thoughts...)

[fosrias]

@sheavalentine-mdsol Makes sense till:

and again you can subselect http://some.hale.doc/resource#self/href

What would be a reason to subselect the href of a link?

[sheavalentine-mdsol]

I don't know that there's a /good/ reason, but it makes the interpretation of fragments generic.

[HonoreDB]

I've argued in email that if you've written your profile such that you expect to get a fragment request, you've written your profile wrong. If an attribute could reasonably be used as a profile in itself, it should be its own profile. Otherwise we risk the absurdity of having all references to the button type have a profile living at /betamax_player#button.

Right now you can serve HALE docs from pastebin if you want, do we really want to lose that?

[sheavalentine-mdsol]

I should clarify.
I would assume that a fragment is a client directive. So, a url fragment can point to a particular part of a resource. The service would ignore the fragment - I'm just suggesting the client has a non-ambiguous way of understanding what is bing pointed to.

[HonoreDB]

Ah, okay, cool. I'm still not sold on this being anything other than an antipattern, though: now we have clients downloading the giant betamax_player profile in order to get the button profile.

But maybe it's inevitable and maybe we should have standards for it.

[fosrias]

Do you see this as a step toward telling clients in meta how access elements of resources, e.g. to build selectors?

[sheavalentine-mdsol]

Okay, so here's the usecase: I am an application hosting Diagnostic Repair Drones. One of the things that relates to my resource is "docking station".
A "docking station" exists as an element in a Leviathan resource, but the service hosting Leviathans is completely uncontrolled by me. Thus, I want to be able to say

"_links" {
  "docks_at" {"href": "http://farscape.services.com/leviathan/1735962#dock1
}

So when a client gets my DRD resource, it can understand that the "docks_at" relationship references a specific element of the Leviathan resource. Thus the client, when semantically binding 'docks_at' can dereference the specific fragment being pointed to.

[sheavalentine-mdsol]

"Do you see this as a step toward telling clients in meta how access elements of resources, e.g. to build selectors?" That certainly would be one use.