Dissillusioned about interoperability.

[Dan Brickley]

Sounds like you could've done with some common abstract data model, and
treated all these different syntaxes as alternate ways of shipping the
same facts around. Is that too crass a thing to say? My personal bias is
towards RDF for the common model, but RDF or no, sounds like there's a
need to be up front about there being multiple ways of expressing the
same underlying information...

Dan

On Thu, 7 Oct 1999, Kent Sievers wrote:

> I am working on a project that is heavily involved with trying to make sense out of data from multiple outside sources.  Years ago when we started out we had our own proprietary way of representing "documents", and had to convert the different formats into ours in order to consume them.  When we first heard about XML we got very excited and have been using it now for quite some time.  But looking back, I have trouble seeing what it bought us.  I will try to use a simple contrived example:
> 
> In the beginning we were shown XMLs that looked like this:
> <Author>
>    <FirstName>John</FirstName>
>    <LastName>Doe</LastName>
> </Author>
> 
> But then we hit the great debate on "attributes vs. elements" and some of the groups that we had to interoperate with said "we prefer elements" and we were forced to handle things like:
> <Author FirstName="John" LastName="Doe"/>
> 
> Reasons varied on why they wanted to do this.  My favorite was "we want to syntactically guarantee that an author has only one last name. "  And we couldn't do anything because they were within their "XML-specified" rights.
> 
> Next we ran into the "meta-data" and schema arguments and we then had groups that wanted to give us things like:
> <Object class="Author">
>      <Property name="FirstName"  value="John"/>
>      <Property name="LastName"  value="Doe"/>
> </Object>
> 
> Reasons varied here as well.  My favorite was "we already have tags in our schema that have spaces and colons in them and we think escaping them would be too much trouble" And we couldn't do anything because they were within their "XML-specified" rights.
> 
> Finally, the "display and rendering" issues came up (e.g. what is easy vs. what is hard using style sheets and IE5) and groups started wanting to give us things like:
> <Object class="Author" label="Author">
>      <Property name="FirstName" label="First name"  value="John"/>
>      <Property name="LastName" label="Last name"  value="Doe"/>
> </Object>
> 
> or
> 
> <Object class="Author" label="Author">
>      <Property name="FirstName" label="First name">John</Property>
>      <Property name="LastName" label="Last name" >Doe</Property >
> </Object>
> 
> Reasons varied again.  My favorite was "it is just too hard to provide generic enough style sheets".  And we couldn't do anything because they were within their "XML-specified" rights.
> 
> While these examples are totally contrived, they represent the problem we are facing:
> Even after we have conversions that take care of disagreements over tag names, data types and allowed values (i.e. the point at which we would expect to reap a huge benefit from XML) we are still doing as much conversion as when we had our own proprietary (non-XML) format.
> 
> In essence, because XML has been "flexible to the point of a free-for-all" when it comes to representing "simple name/value pairs", we have almost no interoperability.
> 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)