[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XML "Web" services (was: RE: xml:href, xml:rel andxml:type)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|