« JSON Schema: Why and How | Main | Whypermedia: Why use Hypermedia? »

Wednesday, May 04, 2016

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Herbert Van de Sompel

Thanks for this posting, Erik. But it leaves me hungry in two ways:

First, the title suggests that the posting would explain when the use of "profile" defined in RFC 6906 is appropriate and when the use of "type" defined in RFC 6903 is. But it doesn't. By the way, given that the "type" attribute has been used since the dark ages to convey MIME type, I am baffled that someone was able to register "type" as a link relation. That's begging for confusion. But that's another story.

Second, I had hoped for an explanation as to why the use of e.g. an XML Schema URI as the Target IRI of a link with the "profile" relation type is or is not appropriate to provide additional information about a resource with media type "application/xml". A recent poll you did via Twitter seemed to suggest it is not appropriate. And, honestly, having read RFC 6903 several times, I can't figure out why that would be. As far as I can tell, a schema expresses a constraint.

I look forward to your feedback, especially because I am involved in a project that really needs solid information re the above questions.

Cheers

Herbert

dret

Thanks for your comment, @herbert. Here's my response, but as usual, that's just my view of things, and very often it's more productive to discuss concrete scenarios and applications instead of just doing spec exegesis. But since i have written the one in question, that's what i was indulging in with this post...

1) Have you seen "type" being used for indicating a MIME type? That would be terrible, since that's definitely not what it's for. I have not seen it used much, and the spec is very fuzzy and talks about linking to an "abstract semantic type": https://tools.ietf.org/html/rfc6903#section-6

i am not sure what that's supposed to mean, and one of the REST principles is that the "type" of a resource in indicated by its MIME type, period: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven "A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client."

The idea behind profiles is that they are optional hints: things continue to work without them, they are just convenience labels you might use to refer to a certain "property bag" that you use or expect to be used. That's very different from a type.

2) A profile says "This animal says you can treat is a duck". A schema says "here are all the rules an animal needs to follow to be considered a duck". A profile might have a schema, but very often instead of that, the schema governing it will be that of the underlying media type, plus additional constraints which often are extensions.

Consider the podcast: The podcast spec does not provide a schema replicating all feed constraints and adding the podcast fields. It could, but that's not what I would do and frankly, I have never seen it done that way. Instead, the schema governing the podcast is still whatever schema defines a feed (let's assume the RELAX NG for Atom), and the profile simply identifies the set of properties that's used in addition to that schema.

As a result, a podcast, when linked as extensively as possible could link to its schema which would be the vanilla feed schema, as well as its profile, which would be the podcast feed identifier URI (which is just an identifier and not a locator, per spec).

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Flickr