Xml Techniques

[Mark Birbeck]

Lisa, I assume Steven is actually referring to the difference between
using XML for document mark-up and using XML for other applications, and
is asking whether most work is still being done with the former, or the
latter. (Although thanks for the update on your products!)
 
For my two-penneth worth, I think the areas Steven mentions - XML-RPC
and SOAP - and the one that Lisa refers to, WebDAV, are going to be more
significant than even the XML revolution itself. Is this possible, I
hear you ask? Bigger? Surely not?
 
Well, yes, because although a standardised document mark-up is a great
step forward, the issue of exchanging that information is still posed.
Systems have to understand each other, and even if the documents that
they communicate are standardised, the manner of their communication
must be too. Steven asked for examples. We recently did another
recruitment site, and decided as an experiment to see how far we could
integrate the client's existing systems with our web server's database,
with as little disruption as possible to their existing processes. Now
the document mark-up standpoint would emphasise that we should use a
standard format for the vacancies and CVs - although finding a good one
is difficult. But surely more interesting is finding a means of
conveying that information that can be used time and again. In the end
we used SOAP; we placed a SOAP client and server on their intranet so it
could see their database, and then allowed it to talk to our server. No
ODBC connections, DCOM problems or firewall gotchas. And we can use the
whole technique again, regardless of whether the next client has a
relational, object or ferret database. As I've said before, I think SOAP
is a real step forward on XML-RPC, so if you're about to look at
XML-RPC, go straight for SOAP. It's a little extra work, but worth it.
But both of them are a real leap ahead of the many other distributed
techniques that end up being quite proprietary.
 
Another technique that I think will really take off is WebDAV. Lisa
referred to it in relation to Exchange. For a site we recently got
going, we have to deal with five publications three of which are weekly.
These come out of PageMaker, but get stored as XML for the usual
reasons. Now again, it is easy to get distracted by what seems to be the
issue - what standard should we use to structure the articles? Well, we
went for XMLNews, but we can change it at any time by updating our
schema, so who cares? The really tricky bit is how to give
geographically separate journalists the ability to import articles to
the system in a quick and reliable fashion. Well, we wrote a WebDAV
layer that sits on top of the XML store. For now, users navigate through
the store with Microsoft's Web Folders because it's a readily available
WebDAV client, but now we've proved the concept we will replace that.
They drag the article in HTML (exported from PageMaker) into the Web
Folder, which sends it to our WebDAV server, which then converts it to
XHTML (tacking on one of the three namespaces - told you you needed
three ...) applies the stylesheet applicable to the folder imported into
and then imports the resulting structure into the store.
 
Now, any WebDAV client could be used here - and obviously someone will
come up with the ultimate publishing client, someone else will come up
with the ultimate e-commerce client. But also we now have a standard way
of controlling data in remote systems. So if we decided to write the
ultimate publishing client, but later decided to move all of the
profiles on politicians into the upcoming Exchanged server - which Lisa
pointed out will be WebDAV-enabled - all we would have to change is a
URL. The application would stay the same. Imagine doing that with your
ODBC connections!
 
[The site is at http://www.parlicom.com but please treat this as a
preview. There'll be no fanfare till January. Note that the URLs for
articles and contents pages use nearly-XPath - a world where strings
have no quotation marks and attributes think they're elements. Also note
that if you take the URL for an article and drop the filename bit, you
will get the XML for that article wrapped up as a fragment. I wouldn't
bother querying for other stuff because the store is in version -9.8 at
the moment, and unless the document is in our cache, retrieval will be
very, very, very, slow.]
 
Anyway, my point is simply that the communication of this information is
the next 'big thing' for developers to get stuck into. Document mark-up
is pretty obvious - you gotta have it. But to build an information-based
internet, we need to get the servers talking to each other!
 
Regards,
 
Mark
 
Mark Birbeck
x-port.net Ltd.
 
 
 

-----Original Message-----
From: Lisa Lippert (Dusseault) (Platinum) [mailto:lisal at microsoft.com]
Sent: Thursday, October 28, 1999 2:39 AM
To: Steven Livingstone; XML Dev
Subject: RE: Xml Techniques


Not sure what you're talking about...
 - If you're talking about traditional email messaging type features,
the next version of Exchange will expose some email properties in XML
over DAV.
 - If you're talking about document markup, Office 10 already supports
document metadata in XML, and the next version of Exchange will expose
that over DAV.
 - If you're talking about some combination of the two, then I don't
understand what the question is :)
 
I'll be discussing the Exchange XML functionality at the upcoming XMLOne
conference in Santa Clara on November 11.  
 
Lisa

-----Original Message-----
From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
Steven Livingstone
Sent: Thursday, October 21, 1999 5:08 PM
To: 'XML Dev'
Subject: Xml Techniques


I am interested in how popular XML has become for messaging type
features (eg XMLRPC and SOAP etc...) relative to traditional document
markup? - I see two distinct, but (possibly) similar markets.
 
Any exciting project undergo?
 
Thanks,
Steven
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991028/4cd995e9/attachment.htm