RE: [xml-dev] RE: Data Interoperability ... Why do some XMLvocabularies

[Liam R E Quin <liam@w3.org>]

On Fri, 2010-08-20 at 12:53 -0400, Costello, Roger L. wrote:

> Consider XSLT. I can create an XSLT document and run it on my XSLT
> processor. I can send the XSLT document to you and you run it on your
> XSLT processor. We get the same behavior. We agree perfectly on what
> the <xsl:for-each> element means and how it should behave. Ditto for
> all the other elements and attributes in the XSLT vocabulary.
> 
> We have successfully interoperated. 
> 
> What enabled this?

(1) XSLT uses an XML syntax. The "XML Promise" is that any XML processor
is licensed by the XML Specification to read any XML document, and to
make that true, XML processors 9including parsers) must implement XML as
documented in the specification.

(2) The XSLT specification is, by and large, a well-produced document.

(3) There's a sufficient community of XSLT users who complain about
deviations from the XSLT (and XML) specifications.

(4) The specifications are esaily and freely available, so that it's
easy for people to check them.

> 
> What enabled the interoperability is the fact that we are using the
> same Prime App. (You may be using Xalan and I may be using Saxon; they
> both belong to the same class of Prime Apps.)

If it helps you to invent a term to describe the points I made above, go
ahead; I don't think "Prime App" is such a good term, though.

If you and I were using C compilers back in 1985 (say), we'd understand
that a C program had to be changed when you moved from one compiler to
another (there was no standard); if we we using Fortran compilers we
might have been better off, since there were standards, although it's
unlikely we'd have had access to copies, making it harder to report
bugs.

People spend (collectively) hundreds of millions of dollars each year in
writing HTML that will work in multiple Web browsers - the interop story
there is weak, largely because of a misapplication of "Postel's Law" in
the past (be liberal in what you accept and strict in what you put out):
the onus should not be on the recipient to correct errors, but on the
sender to emit correct data. Being liberal in what one receives does not
mean bending over backwards (or forwards) because the sender hasn't
bothered with the "strict" part. Of course, XML forces correctness and
does not have much of the "liberal", but at least we get
interoperability that way.

It's not at all about applications.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Occasional Blog: http://www.barefootliam.org/