On Friday, January 7, 2005, at 03:53 PM, Danny Ayers wrote:
On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote:Could you give an example of something useful that a real world application would be enabled to do?
Off the top of my head, how about categorizing entries by their properties.
I don't understand. Could I get some example XML, and if the XML doesn't make it obvious, an explanation of how RDF makes this possible where it's not possible lacking RDF?
But being able to mix extensions in a predictable fashion is generally nice to have. Last time I looked my own RSS 1.0 feed was using terms from 9 namespaces (mostly through the FOAF output plugin). I could merge with lots of other peoples RSS 1.0 feeds and be sure all the same information would still be available. If it wasn't mapped to a common model (through the structure) I wouldn't even know how to merge.
Again, I don't understand. When you talk of merging feeds, do you mean making a feed out of entries from separate feeds (but where the entries themselves are not altered), or merging the entries themselves, where sometimes the feeds contain different instances of the same entries, resulting in entries containing more data than exists in any one feed? Either way, what information might become unavailable in the process? Maybe once I understand the foregoing, I'll also understand "mapped to a common model (through the structure)".
Let me see if I've got this right: you're saying that by standardizing on putting data in element content vs. in attributes, the code would only have to support getting values from element content, and not have to bother with getting attributes? Having typed that sentence, it seems I must be missing something, because the following pseudocode snippets seem only trivially different to me:It's also one less job (per extension) for every single developer that
wishes to support extensions. This particular part of their code would
only have to be written once.
Off the top of my head, I can't imagine how this would impact the amount of code required in an application. Could you elaborate?
Ok, say x,y come from one extension (geo) and magnitude another (seismo). The client receives something like this:
<entry> <geo:x>10.1</geo:x> <geo:y>57.3</geo:y> <seismo:magnitude>7</seismo:magnitude> </entry>
a bit of code could pick these values up with characters[] in SAX or a text node in DOM or whatever XOM sees, but the thing is both geo and seismo are following the same structure
but if geo and seismo did things a little differently:
<entry> <geo:coords x="10.1" y="57.3" /> <e:magnitude>7</e:magnitude> </entry>
a bit of code could pick the magnitude value up as before, but the coords would need different handling - SAX would have to go poking in attributes, DOM would need a getAttribute(), XOM would - ok, I've no idea, but I expect something different.
geox = GetElementContent("/geo:x");
geoy = GetElementContent("/geo:y");
magnitude = GetElementContent("/seismo:magnitude");geox = GetAttribute("/geo:coords/@x");
geox = GetAttribute("/geo:coords/@y");
magnitude = GetElementContent("/seismo:magnitude");I'm assuming the client knows something about the geo and seismo extensions--otherwise, I can't imagine what the client would be doing with the extension elements anyway (beyond ignoring it, storing it in an "unknown extension" table, or passing it through to some other application).
