\nSo, for the same of argument, yesterday I threw together\nexamples\nof what a use of RSS-Data might look like alongside what\nthe same data in an RSS namespace extension might look like.\nI promised code, but never got a chance to circle back around.\nFortunately, Phillip Pearson\nconnected the rest of the dots for me with two examples:\n
\n\n\n\n\nI was just a little surprised by his results, since I expected\nthe code to handle an RSS namespace to be at least a bit more complex\nthan the RSS-Data example. But,\nas Phillip observed later,\nthe scripts were pretty much equivalent in length, complexity, and\nease of construction.\n
\n\nThen, this morning, I saw that Danny Ayers had posted an\nexample in RDF\nof this same data. It doesn't differ very much from my namespace\nextension example, except that the few differences there are enables\nhis example to flow through RDF tools (as well as, usually, XML tools like\nXPath and XSLT).\n
\n\nIn a comment\non one of Phillip's posts, though, Roger Benningfield makes\nthe point that this example is a bit biased:\n
\n\nI agree that there won't be a ton of difference between a struct full\nof strings and plain ol' XML. But that's kind of a stacked example,\nsince SDL would allow a lot more than that... arrays, integers, and\narrays of integers inside structs.\n\n\n\n
\nWhat I did could be obscuring some work. I just took an existing\nschema from Amazon, which gave me some initial work already for free.\n(Though, there's something to be said for that in and of itself.)\nThe structures were already established, and the schema was created\nwith XML representation already in mind. This could have placed\nRSS-Data at an example. While I really don't think\nthat XML-RPC serialization offers more flexibility in expression than\nXML itself, I could be wrong and I don't want to be tilting\nat straw men. \n
\n\nSo, while I doubt that I'll have a whole lot of time today, I think\nfor the same of completeness, someone should go through the parallel\nprocesses of going from problem statement up through data modeling and\non to production and consumption of RSS-Data and an RSS namespace\nextension. While doing this, capture the work involved in both.\n
\n\nI could see shortcuts taken on the RSS-Data side, since you don't have\nto be concerened with various bits of XML tech like DTDs or schema\nor whatnot. You can jump right into coding up an example usage and\ncome up with your data model on the fly. Whether this is a good thing\nor not, I'm sure many will disagree. Also, I'm sure others would\ngo through this differently than I would. Again, your mojo may\nexceed mine.\n
\n\nAt this point, I can see the benefits of RSS-Data in rapidly cobbling\ntogether scripts, but I lean toward having a decently defined data\nmodel first. You can do this in your scripts, but using the existing\nXML tech forces you through some specific processes. On the other\nhand, I can see where some busy developers don't have time or spare\nbrain cycles to absorb all the XML tech. It could be made easier\nat that end of things, which is where I'd rather spend my effort.\n
\n\nAnyway, I'm really interested in seeing where this goes, because\nthis comparison of RSS-Data, RSS namespace extensions, and even\nRDF seems like another very concrete, non-theoretical way to demonstrate\nthe benefits and drawbacks of these ways of thinking about data\nand interoperability.\n
\n\n\n\n\n\nshortname=rss_data_versus_namespace_3
\n", "body": "\r\nSo, for the same of argument, yesterday I threw together\r\nexamples\r\nof what a use of RSS-Data might look like alongside what\r\nthe same data in an RSS namespace extension might look like.\r\nI promised code, but never got a chance to circle back around.\r\nFortunately, Phillip Pearson\r\nconnected the rest of the dots for me with two examples:\r\n
\r\n\r\n\r\nI was just a little surprised by his results, since I expected\r\nthe code to handle an RSS namespace to be at least a bit more complex\r\nthan the RSS-Data example. But,\r\nas Phillip observed later,\r\nthe scripts were pretty much equivalent in length, complexity, and\r\nease of construction.\r\n
\r\n\r\nThen, this morning, I saw that Danny Ayers had posted an\r\nexample in RDF\r\nof this same data. It doesn't differ very much from my namespace\r\nextension example, except that the few differences there are enables\r\nhis example to flow through RDF tools (as well as, usually, XML tools like\r\nXPath and XSLT).\r\n
\r\n\r\nIn a comment\r\non one of Phillip's posts, though, Roger Benningfield makes\r\nthe point that this example is a bit biased:\r\n
\r\n\r\nI agree that there won't be a ton of difference between a struct full\r\nof strings and plain ol' XML. But that's kind of a stacked example,\r\nsince SDL would allow a lot more than that... arrays, integers, and\r\narrays of integers inside structs.\r\n\r\n
\r\nWhat I did could be obscuring some work. I just took an existing\r\nschema from Amazon, which gave me some initial work already for free.\r\n(Though, there's something to be said for that in and of itself.)\r\nThe structures were already established, and the schema was created\r\nwith XML representation already in mind. This could have placed\r\nRSS-Data at an example. While I really don't think\r\nthat XML-RPC serialization offers more flexibility in expression than\r\nXML itself, I could be wrong and I don't want to be tilting\r\nat straw men. \r\n
\r\n\r\nSo, while I doubt that I'll have a whole lot of time today, I think\r\nfor the same of completeness, someone should go through the parallel\r\nprocesses of going from problem statement up through data modeling and\r\non to production and consumption of RSS-Data and an RSS namespace\r\nextension. While doing this, capture the work involved in both.\r\n
\r\n\r\nI could see shortcuts taken on the RSS-Data side, since you don't have\r\nto be concerened with various bits of XML tech like DTDs or schema\r\nor whatnot. You can jump right into coding up an example usage and\r\ncome up with your data model on the fly. Whether this is a good thing\r\nor not, I'm sure many will disagree. Also, I'm sure others would\r\ngo through this differently than I would. Again, your mojo may\r\nexceed mine.\r\n
\r\n\r\nAt this point, I can see the benefits of RSS-Data in rapidly cobbling\r\ntogether scripts, but I lean toward having a decently defined data\r\nmodel first. You can do this in your scripts, but using the existing\r\nXML tech forces you through some specific processes. On the other\r\nhand, I can see where some busy developers don't have time or spare\r\nbrain cycles to absorb all the XML tech. It could be made easier\r\nat that end of things, which is where I'd rather spend my effort.\r\n
\r\n\r\nAnyway, I'm really interested in seeing where this goes, because\r\nthis comparison of RSS-Data, RSS namespace extensions, and even\r\nRDF seems like another very concrete, non-theoretical way to demonstrate\r\nthe benefits and drawbacks of these ways of thinking about data\r\nand interoperability.\r\n
\r\n\r\nshortname=rss_data_versus_namespace_3\r\n", "parentPath": "./content/posts/archives/2003", "path": "2003/10/03/rss-data-versus-namespace-3", "summary": "So, for the same of argument, yesterday I threw together\nexamples\nof what a use of RSS-Data might look like alongside what\nthe same data in an RSS namespace extension might look like.\nI promised code, but never got a chance to circle back around.\nFortunately, Phillip Pearson\nconnected the rest of the dots for me with two examples:\n\n\nParsing RSS-Data\nParsing an RSS namespace extension\n\n\n\n\nI was just a little surprised by his results, since I expected\nthe code to handle an RSS namespace to be at least a bit more complex\nthan the RSS-Data example. But,\nas Phillip observed later,\nthe scripts were pretty much equivalent in length, complexity, and\nease of construction.\n\n\nThen, this morning, I saw that Danny Ayers had posted an\nexample in RDF\nof this same data. It doesn't differ very much from my namespace\nextension example, except that the few differences there are enables\nhis example to flow through RDF tools (as well as, usually, XML tools like\nXPath and XSLT).\n\n\nIn a comment\non one of Phillip's posts, though, Roger Benningfield makes\nthe point that this example is a bit biased:\n\n\nI agree that there won't be a ton of difference between a struct full\nof strings and plain ol' XML. But that's kind of a stacked example,\nsince SDL would allow a lot more than that... arrays, integers, and\narrays of integers inside structs.\n\n\n\n\nWhat I did could be obscuring some work. I just took an existing\nschema from Amazon, which gave me some initial work already for free.\n(Though, there's something to be said for that in and of itself.)\nThe structures were already established, and the schema was created\nwith XML representation already in mind. This could have placed\nRSS-Data at an example. While I really don't think\nthat XML-RPC serialization offers more flexibility in expression than\nXML itself, I could be wrong and I don't want to be tilting\nat straw men. \n\n\nSo, while I doubt that I'll have a whole lot of time today, I think\nfor the same of completeness, someone should go through the parallel\nprocesses of going from problem statement up through data modeling and\non to production and consumption of RSS-Data and an RSS namespace\nextension. While doing this, capture the work involved in both.\n\n\nI could see shortcuts taken on the RSS-Data side, since you don't have\nto be concerened with various bits of XML tech like DTDs or schema\nor whatnot. You can jump right into coding up an example usage and\ncome up with your data model on the fly. Whether this is a good thing\nor not, I'm sure many will disagree. Also, I'm sure others would\ngo through this differently than I would. Again, your mojo may\nexceed mine.\n\n\nAt this point, I can see the benefits of RSS-Data in rapidly cobbling\ntogether scripts, but I lean toward having a decently defined data\nmodel first. You can do this in your scripts, but using the existing\nXML tech forces you through some specific processes. On the other\nhand, I can see where some busy developers don't have time or spare\nbrain cycles to absorb all the XML tech. It could be made easier\nat that end of things, which is where I'd rather spend my effort.\n\n\nAnyway, I'm really interested in seeing where this goes, because\nthis comparison of RSS-Data, RSS namespace extensions, and even\nRDF seems like another very concrete, non-theoretical way to demonstrate\nthe benefits and drawbacks of these ways of thinking about data\nand interoperability.", "needsBuild": true, "prevPostPath": "2003/10/02/rss-data-versus-namespace-2", "prevPostTitle": "RSS 2.0 namespace versus RSS-Data, Part 2: First impressions", "nextPostPath": "2003/10/03/a-quick-irc-soap-primer", "nextPostTitle": "A quick SOAP primer via IRC (but not SOAP via IRC)" }