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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Relating to XML

[ Lists Home | Date Index | Thread Index ]

It is this narrow approach to split data into different categories that
XML transcends. Together with the simple and standardized (single)
syntax, this simplifies interoperability of documents AND data.

Oh well, I know that I will never get Alaric to see beyond this narrow
markup text -> XML, data -> something else (like ASN1) division.

Best regards
Michael

> -----Original Message-----
> From: Alaric B Snell [mailto:alaric@alaric-snell.com]
> Sent: Friday, November 21, 2003 12:28 PM
> To: Baiss Magnusson
> Cc: XML-DEV
> Subject: Re: [xml-dev] Relating to XML
> 
> Baiss Magnusson wrote:
> > I have a direct to java client web application which parses a XML
file,
> > I designed the XML syntax, of recipes into Enterprise Objects
(EO's).
> >
> > My question is: How does one go about creating interoperability with
> > other applications?
> > For instance, there is another cookbook application around which has
an
> > export function and produces an XML type file of similar, but
slightly
> > different tag syntax than my cookbook program. I would like to
import
> > it's recipes.
> >
> > Is there something about XML services that I am missing?
> 
> Nope - XML doesn't magically make things interoperate; just as with
any
> other data format, both ends need to be aware of the meaning of the
> information you're passing back and forth to make sense of it!
> 
> So you define XML formats - like XHTML, SVG, and so on - specifying
what
> elements go inside what other elements, and documenting what they
> *mean*. Both applications must stick to the same spec to acheive
anything.
> 
> There has been much hype to the tune that XML somehow improves
> interoperability, but alas, there is no real truth behind it.
> 
> Using XML for data interchange isn't always the best solution, anyway;
> XML is far better suited to document-type formats, where the content
you
> are exchange is (at heart) a single string of text with structural and
> styling information supplied by the elements. If your XML looks like
this:
> 
> <para>text text text text text text text text
> <productName>foo</productName> text text text ...
> 
> ...then everyone seems to agree that XML is good, but when you start
to
> get stuff more like:
> 
> <purchaseOrder>
>    <transactionId>12345-2341234</transactionId>
>    <items>
>      <item>
>        <code>G345</code>
>        <qty>10</qty>
>      </item>
>    </items>
> </purchaseOrder>
> 
> ...then you may find it easier to stick to better-established
standards
> for such things, like CSV files!
> 
> My personal measure of when XML is being used outside of its domain is
> to think about what the content would look like if I just stripped out
> all the elements. The first example comes out as:
> 
> text text text text text text text text foo text text text...
> 
> Which, had I written some better example prose than 'text', would make
> some sense, whereas the purchase order comes out as:
> 
> 12345-2341234 G345 10
> 
> ...which suggests this is really data being exchanged, rather than a
> document.
> 
> But plenty of others will disagree... :-)
> 
> ABS
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 






 

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

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