- From: Rob Sanderson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Dec 2015 18:36:33 +0000
- To: public-annotation@w3.org
As @iherman says here https://github.com/w3c/web-annotation/issues/30#issuecomment-165180831, the media type for JSON-LD is application/ld+json. Our representation is JSON-LD, and hence we cannot prevent anyone from using that media type. The addition of a profile lets the JSON-LD media type be more specific as to the structure of the JSON in the representation. So it is orthogonal whether we want to mint _another_ media type for it as well. And my opinion is that we should not force implementers to choose which to use, and as we have a media type already, we should just use it. The rationale for a profile rather than yet another media type is that it is recognizable as JSON (+json), as JSON-LD (ld+json) and as an Annotation (the profile) all at the same time, without further adding to the global pool of media types. After the confirmation from IETF that we can register a file extension for a profile, I see no downside ... ... as the "clumsiness" is actually a feature. There are several other parameters on media types including charset. Any reasonable implementation will check for these on the client side, and it's just a string to add to the response header on the server side. So it's actually pretty elegant, from my perspective. -- GitHub Notification of comment by azaroth42 Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/125#issuecomment-165205963 using your GitHub account
Received on Wednesday, 16 December 2015 18:36:34 UTC