[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RDF vs. SOAP serialization (oh yeah, and XMI and XTM)

  • From: Uche Ogbuji <uche.ogbuji@f...>
  • To: David Megginson <david@m...>
  • Date: Fri, 22 Dec 2000 11:17:04 -0700 (MST)

rdf reification serialization

> Dave Winer writes:
>
>  [on static data representation]

Oh, is that what he was getting at?

>  > If that's what RDF is going to be used for I'd strongly recommend
>  > using the serialization format in XML-RPC or SOAP. They both work
>  > incredibly well, and are supported in lots of environments and are
>  > understandable, very simple stuff that allows data structures to be
>  > exchanged between apps on all platforms. Something to think about?
>  > Dave
>
> I don't think that XML-RPC is really in the running -- I'd suggest
> that the main candidates for a general-purpose XML data format right
> now are RDF and SOAP (as Dave mentions), with XMI and XTM running a
> very, very distant third.

OK, David, so maybe you can help me out here.  Why would any one even
suggest RDF qua RDF as a "general-purpose XML data format"?  What does
this even mean?  Does this mean that if I don't have a schema in mind,
that I wrap my xml in an <rdf:RDF> element and conform to the RDF M&S?
Yikes.  even an RDF booster such as I would scarecely suggest such a
thing.

If the data were more POP-oriented, I would probably use Docbook.  If it
were more MOM-oriented, I'd probably use WDDX.  If the data were a stretch
for either format, I'd probably just spend the little time it takes to
come up with a workable custom schema.  In any case, I'd take a few
moments to see if someone had done the like before.

But for me to seize on RDF would, IMO be making the false assertion that
every arbitrary data field is metadata.  Yes one man's data is another's
metadata, but trying to have a workable metadata graph is pretty
difficult when the whole kitten kaboodle is shoe-horned into the
structure.

SOAP serialization does make more sense here, but frankly it's too ugly
for me to adopt for my use.  Note that this is more of a visceral opinion
right now, just having completed a little SOAP project.  It's not the
product of detailed analysis.

> On the other hand, both specs suffer from painfully muddled design --
> the RDF spec dumps reification and knowledge-representation junk on
> top of what would have been a simple foundation, while the SOAP spec
> mixes protocol and format (-20 each).

I say "bingo" on your criticism of SOAP, but I don't see your point about
RDF.  RDF is _designed_ for knowledge-representation.  How can it be other
than it is?  Again, I don't think it's designed for general-purpose data
format.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@f...               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.