Henry Story wrote:
By the way, apart from the point mentioned in this thread, I think the
current app spec is very good, and a great step forward on what has
existed before. I am sorry if my thread started off with the wrong tone.
It is difficult sometimes to get tone right.
On 6 Jul 2006, at 06:23, Alex Milowski wrote:
Henry Story wrote:
So here goes: the service document contains nearly no information.
Why is it needed? Why have a whole mime type for what is pretty much
an empty document.
In my service, where I have a hierarchy of collections and lots of
collections, the service introspect document is quite full of pointy
brackets.
Could you point me to this? I'd like to see the whole implementation
from beginning to end. Ie. The user starts somewhere (a web page?) gets
to the introspection document and then does something with it.
...oh, ok. I guess now is as good as a time as any.
I added Atom protocol support to the eXist XML database. That project
is open-source and hosted at http://www.exist-db.org
Unfortunately, it isn't documented yet. That documentation will
be finished for a release on July 15th.
I'll announce that again when I finish the documentation.
I have no doubt that individual <service> documents can contain a lot of
information. The problem is: it is mostly the same type of information:
a url pointing to a feed with some info on what mime types that feed
accepts. If that is all the info there is in there, then it seems to me
a little expensive to create a whole new mime type for such a document.
Especially as there seems to be an obvious location to place this
information: the feed itself.
Sometimes a directed syntax is more appropriate. I've tried to fit
certain kinds of information into Atom feeds and it became unworkable.
I'm not convinced that this is the case for introspection but it
doesn't bother me as long as it comes back as pointy brackets.
But those that have tried to put forward new ideas in this area have
always been shot down on technicalities. This is why I think one has to
start with something more forceful: namely that we have unnecessary
complexity in the protocol as currently presented, with commensurate
reduction in functionality (unnecessary complexity as we know from the
soap experience is not a good thing).
Hmmm.... I haven't had that experience. While people may have strong
opinions, all my interactions have been good. I've had ideas rejected,
but that is just part of developing a specification.
--Alex Milowski
