Lists Home |
Date Index |
> I'd go further. I think the current RDF/XML syntax is so B.A.D. (broken
> as designed) that it has seriously got in the way of people being
> open-minded about RDF. I'm baffled why the RDF working group has been
> forbidden to work on replacing that syntax. -Tim
Because, Tim, there are implementations of RDF/XML as described, including
Mozilla and RSS 1.0. I know you don't approve of them, but they are real,
they are production, they are in use. Bitch about them as much as you want,
but people use them.
Someone mentioned recently that as grand as it sounds to just throw out a
spec when everyone decides that it's "bad", one has to take into account
existing customers. This includes at least 50+ tools and apis that are built
on the existing RDF/XML, not to mention applications that are using these
tools, APIs, and the RDF/XML as written.
HTML was also "bad". But when XML came along we didn't throw out HTML
immediately. No, we came up with what is a compromise -- XHTML. It's a start
towards moving people in the right direction. It isn't perfect, but few
things in life are perfect.
The RDF Working Group was given a charter not to rewrite RDF/XML but to
answer issues and provide as much cleanup and clarification as they could
but to still remain within that support for previous implementations. It's
sad that one can't just throw things out and start over again, but that's
the way of the real world.
You came up with a RDF/XML that you say meets all of the requirements of the
RDF model. Well, promote it and prove that it meets all the requirements of
the RDF model. Then we'll use transformation to either convert your RDF/XML
version to the one in the standards, or we won't because perhaps people will
dislike yours too. In fact, as contentious as the XML world is, we can
guarantee that people will find fault with whatever you come up with. With
what anyone comes up with. It's a fact of a life.
But don't just come along and say it's "bad" without coming up with a plan
that will allow a better version to co-exist with previous implementations,
and a strategy for deploying its use, all of which people will like _and_
that will meet the existing logically proven data structure behind RDF,
which you don't seem to mind. And if you do come up with all of this, why,
most likely I'll support your effort as much as I'm now supporting the
existing implementation of RDF/XML. I am nothing if not open minded.
But I do tire of people saying "bad", without specifics and solutions.