On Tue, May 20, 2008 at 1:14 AM, JabberForum <[EMAIL PROTECTED]> wrote: > > I don't really understand your point... This is not the syntax of > pubsub node, this is the syntax of http. They are just different, hence > you cannot write them the same!
I disagree. My point is that if the spec allows using HTTP URIs as PubSub nodes (it does), then you can write them the same. If they produce the same content, then they are the same, just over different transports. By making the nodes and urls equivalent, the accessibility for developers writing code against APIs increases dramatically. > Moreover, the view which would filter > only some category/tag/etc. on a blog is dependant on the blog > implementation. It is not a generic standard. No, it's not a generic standard. However, the web works really well, and has more adoption than XMPP. Moreover, there have been attempts to normalize URL structure (see: WS-* vs. REST) which have failed pretty miserably. > With a blog system, it > could be the url you showed, another could contain the category directly > in the address, etc. And even in a single blog system, you can often > choose how will be displayed the address (look at the "permalink" > feature of Wordpress). This is up to the implementation because anyway > there is nothing like tag or category in http/html standards. Yes (I agree). > In XMPP, there is not either for now, so we could try to "simulate" it, > the same way it is simulated in http, witht he difference there is less > possibility (no script language like php or other to generate dynamic > pages, all is static in pubsub). Not true. I've written dynamic PubSub handlers in Ruby (i.e., PubSub handlers that could support query strings), and it's easy enough to do so in any language. If you're accepting tags in some other form, e.g. <field />, then you're writing a dynamic PubSub handler anyways. > But I think we could enhance the > protocol by adding a category and tag notion, as this kind of notion is > clearly linked to publications (and pubsub is about publication!). See the debate of WS-* to REST. Currently the protocol has support for this, but uses URLs (!) to define keyword semantics. The example given in the spec is: <field var='http://shakespeare.lit/search#keyword' type='text-single' label='Keyword to match'/> Moreover, XEP-0060 is 43,103 words long, which translates to about 172 pages of printed text. The chances of a keywording system being added to a PubSub architecture are pretty slim, I have to say. It's better to just accept the fact that usage will be diverse and let people develop their own methodologies for handling these things. b.
