hello.
On 2011-05-03 7:05, Hadrien Gardeur wrote:
Sure, it's not likely at all to happen in the mid term, but with media parameters you're not "breaking" anything either. If we want those specifications to evolve, we need more examples and people interested in those parameters. The AtomPub spec with its "type" parameter for Atom is a good start but we need to go further.
like i said before, philosophically, i do agree that this would be cleaner and the better approach. but we would need to update the atom spec which, as i am reading it, does not allow for extensibility of media type parameters:
http://tools.ietf.org/html/rfc4287#section-7 says that the only allowed parameter is "charset". i think the way to go for all of this to be nice and clean would be to add a "content-type" parameter, which as a value would have a media type (the media type of the content embedded or linked to by the feed). this raises two questions:
- is that kind of parameter value even allowed in a media type? and if it is, how many media type parsers might possibly break because a media type would contain "two media types"?
- how realistic is it to update RFC 4287 in that way, which as i understand it would not be backwards compatible?
if that was a realistic way to go, even things such as http://www.w3.org/TR/html5/links.html#rel-alternate might need to be updated, so that the new features would be allowed/supported (and shouldn't HTML5 allow the optional charset parameter that is possible according to RFC 4287?).
any feedback on this would be greatly appreciated. kind regards, dret. -- erik wilde | mailto:[email protected] - tel:+1-510-6432253 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret |
