[
Lists Home |
Date Index |
Thread Index
]
> > 1 - Politics happens, Evolution is continuous, deal with it.
> > With technology, as best you can. Don't make technology choices
> > that are fragile in the face of human nature.
>
> I would add: "Don't make technology choices
> that are fragile in the face of the currently available
> toolsets." For example, using RDF in RSS 1.0.
What does this mean? You might want to look at the impressive variety of RDF
tools listed at
http://www.ilrt.bristol.ac.uk/discovery/rdf/resources/
before answering.
> > 2 - Namespaces - work best for mixing instances of well-defined
> > vocabularies/schemas together, they don't work so well to support
> > evolution or un-typed XML. Schema evolution using namespaces is
> > a Known to Be Hard, TAG-level problem.
>
> I'd generalize your observations here to not just encompass
> schemas but to all types of validation. Validation seems
> anathma to evolvable.
This sounds like the rallying cry of the Knights of Tag Soup.
Validation is mostly an obstacle to evolution if designed using the wrong
tools in careless hands.
> > If you want to leverage commonly deployed code that understands
> > a specific namespace (XHTML, SVG, etc.), the full-blown Namespaces
> > in XML is your friend, well Real Soon Now anyway. If you just
> > want to disambiguate tags, it has lots of little gotchas
> > (that "RSS 2.0" seems to have been gotten by!) that make it a
> > challenge for people who don't grok its subtleties. (MOST OF
> > THE REAL WORLD!!!)
Let us not forget that most of the real computing world does not grok the
subtleties of XML, Java, HTML, PC architecture, e-mail, or even the Internet.
Time to shut up shop and go home? I think not.
> > 3 - If you don't know exactly what you're dealing with, heuristics
> > beat logic. If the tag is <table> and it has
> > HTML table elements inside it, it's probably an HTML table! Don't
> > throw it away because it's in the wrong namespace.
>
> I'd say that "heuristics beats validation".
How are the two supposedly in a fight, again?
> This gets into the social aspects of RSS as an 'evolvable' format.
> Many of the feeds are produced by some home grown CMS or are
> even created by hand. This highlights the need for a
> format to be as simple as possible.
It's based on XML. Therefore, it is impossible for it to be "as simple as
possible".
> The other aspect is that many people implementing RSS may not
> have read the RSS spec (never mind the XML spec) they're just
> using an example RSS file as boilerplate. Again, another 'tools'
> issue. Paraphrasing a conversation
> I had with another developer when he was talking about creating an RSS feed:
>
> "I thought to my self, I could do this the *right* way and use
> the DOM API in my scripting language and have it take me an hour,
> or I could just use printf and be done in 10 minutes.
> I did the printf thing, it's just a blog."
Again, why bother with XML? WHy not just make it CSV with some hand-waving
notes on structure in the spec? People who "do the printf thing" rarely even
produce WF XML. I see no reason to accommodate such slovenliness. If one
thinks it's necessary to do so in order to accommodate everyman, then they
should dispense with the lie that they are using XML.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
