OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Dissillusioned about interoperability.

[ Lists Home | Date Index | Thread Index ]
  • From: Dan Vint <dvint@slip.net>
  • To: "Kent Sievers" <ksievers@novell.com>, <xml-dev@ic.ac.uk>
  • Date: Thu, 07 Oct 1999 19:36:15 -0400

But do remember back to when you had:

\b;John Doe&b-

and had to find the author name amongst all the other \b; .... &b- markup
and hope that you also didn't catch other values that weren't author names
that happened to be marked up the with the same proprietary markup?

If you XML is a clean as all the varities that you have shown then you are
way ahead in the conversion efforts than someone who is dealing wiht Frame
MIF, Interleaf, Word and WordPerfect codes! Please give me your problems!

Yeah, in your case XML hasn't become a magic bullet, but it certainly is
much easier and more accurate to deal with than pure proprietary  desktop
publishing formats that are only concerned with making pretty pages.

..dan

At 04:05 PM 10/7/99 -0600, 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@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@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>


---------------------------------------------------------------------------
Danny Vint                                       http://www.dvint.com
Author: SGML at Work   	http://www.slip.net/~dvint/pubs/sgmlatwork.shtml 
                                                       mailto:dvint@slip.net
    
Calian                                              Voice:804-975-3482
mailto:d.vint@calian.com
Charlottesville, VA Office                http://www.calian.com              


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS