http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/ XML and the Web. Mon, 13 Oct 2008 09:06:59 +0000 http://wordpress.org/?v=2.5.1 http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/#comment-162 Bill de hÓra Thu, 24 Feb 2005 01:05:02 +0000 /?p=23#comment-162 <strong>Content trumps Architecture</strong> Comments on David Megginson's fifth REST question, and some idle speculation on the shape of content formats to come. Content trumps Architecture
Comments on David Megginson’s fifth REST question, and some idle speculation on the shape of content formats to come.

]]> http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/#comment-161 Bill de hÓra Thu, 24 Feb 2005 01:01:15 +0000 /?p=23#comment-161 <strong>Content trumps Architecture</strong> Comments on David Megginson's fifth REST question, and some idle speculation on the shape of content formats to come. Content trumps Architecture
Comments on David Megginson’s fifth REST question, and some idle speculation on the shape of content formats to come.

]]> http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/#comment-160 AsynchronousBlog Thu, 24 Feb 2005 00:49:31 +0000 /?p=23#comment-160 <strong>RE: REST Design Question #5</strong> Wherein I respond to Dave Megginson's last REST design question. I'm only posting this because I've responeded to the other 4, and value completeness; I find Dave's most recent post/question/argument to be the weakest of the series. Dave's strawma... RE: REST Design Question #5
Wherein I respond to Dave Megginson’s last REST design question. I’m only posting this because I’ve responeded to the other 4, and value completeness; I find Dave’s most recent post/question/argument to be the weakest of the series. Dave’s strawma…

]]> http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/#comment-159 Sjoerd Visscher Wed, 23 Feb 2005 22:07:58 +0000 /?p=23#comment-159 You shouldn't use elements from foreign vocabularies like the Dublin Core. There are often subtle semantic differences between the defined meaning of the elements and the way they seem to be applicable in other vocabularies. Those differences tend to reveal themselves only in practice (when the semantics are actually used, still quite rare on the web). It's better to only use your own vocabulary, and then provide a translation (like f.e. XSLT) to the other vocabularies. When the differences show up, you only have to change the translation, not your format. You shouldn’t use elements from foreign vocabularies like the Dublin Core. There are often subtle semantic differences between the defined meaning of the elements and the way they seem to be applicable in other vocabularies. Those differences tend to reveal themselves only in practice (when the semantics are actually used, still quite rare on the web). It’s better to only use your own vocabulary, and then provide a translation (like f.e. XSLT) to the other vocabularies. When the differences show up, you only have to change the translation, not your format.

]]> http://www.megginson.com/blogs/quoderat/2005/02/23/rest-design-question-5-the-c-word-content/#comment-158 Danny Wed, 23 Feb 2005 21:57:11 +0000 /?p=23#comment-158 Personally I think I'd go with keeping the content (document, data or whatever) orthogonal with the transport. If cross-app format standardization is needed, for docs there's XHTML and DocBook, for data there's RDF/XML and more RDF/XML (this time derived from arbitrary XML via GRDDL). There is a standard way to refer to a non-XML (representation of a) resource, that's a URI plus MIME type. URIs can appear in XML very nicely as rdf:about/rdf:resource attributes. Staying with the RDF theme, note that if you add a default namespace to your DC city example, it becomes valid RDF... Personally I think I’d go with keeping the content (document, data or whatever) orthogonal with the transport. If cross-app format standardization is needed, for docs there’s XHTML and DocBook, for data there’s RDF/XML and more RDF/XML (this time derived from arbitrary XML via GRDDL). There is a standard way to refer to a non-XML (representation of a) resource, that’s a URI plus MIME type. URIs can appear in XML very nicely as rdf:about/rdf:resource attributes. Staying with the RDF theme, note that if you add a default namespace to your DC city example, it becomes valid RDF…

]]>