XML "Web" services (was: RE: [xml-dev] xml:href, xml:rel andxml:type)

["Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>]

Hi Dan,

I forked the thread because I think it stands apart from the original topic.

> I'd encourage you (if you haven't already) to dip into the 
> 1000s of messages and posts that have been written about 
> XHTML 'vs' non-XML HTML (HTML5, WHATWG, etc.).
> 

Thanks for the reminders.  I especially liked James' post, which I read
some time ago and re-read just now.

His description is very accurate (would you expect anything less!).

I also believe that there is a need for bridges to be built between the Web
and XML, which follow simple, yet dare I say, hard-wired patterns.

The value of doing so is described in James' post:

"This is not a good thing for either community (and it's why part of my reaction to JSON is "Sigh"). XML misses out by not having the innovation, enthusiasm and traction that the Web developer community brings with it, and the Web developer community misses out by not being able to take advantage of the powerful and convenient technologies that have been built on top of XML over the last decade."

The way forward is also suggested:

"In the short-term, I think the challenge is how to make HTML5 play more nicely with XML. In the longer term, I think the challenge is how to use our collective experience from building the XML stack to create technologies that work natively with HTML, JSON and JavaScript, and that bring to the broader Web developer community some of the good aspects of the modern XML development experience."


> Most of the fire in those exchanges wasn't about linking 
> notations, but rather around XML's alleged brittleness vs 
> HTML's support for more lax, tag-soup parsing when the 
> content is partly broken.


In terms of "playing nicely with XML", I like atompub because it could be a bridge
from presentation markup to data markup (by URI reference, what else ;-).  HTML5 could (in theory) have tags 
(as yet non-existent, I'm just saying) which require feeds for content, basically anything 
that is "a collection of members" could be subject to such markup.

It does not constrain the MIME media type to application/atom+xml - 
content negotiation allows the server to deliver application/json, 
application/gml+xml, application/etc if demanded.  But application/atom+xml
is the "hard-wired" reliable value.  A big part of the value is the
hard-wiredness of it.  

The simple resource model (Collection + Member) together with the simple
representation model (feed + entry) seem abstract enough to have generality
yet hard-wired enough to have simplicity.  The value of the atom format
is that it seems "widely" understood, also slightly hard-wired. Even some 
web browsers seem to vaguely know of atom format, if not the MIME media type.  
I stress vaguely.

While this may seem like an "envelope" to some, I agree, but because
of content negotiation, a client does not need to deal with the envelope 
part if the service supports a more appropriate media type for it. HTML is
an unlikely candidate for that service because the of the presentation 
semantics.  

To bring the topic back to @xml:href, @xml:rel and @xml:type, maybe those are the
means to directly "web-enable" non-atom XML-based formats with some judicious hard-wiring.
Even if atom becomes the spoken dialect between clients and web services, 
there will still be a need for non-HTML hypertext within the atom envelopes.

Cheers,
Peter