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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: The failure to communicate XML - and its costs to e-business

[ Lists Home | Date Index | Thread Index ]
  • From: Jonathan.Robie@SoftwareAG-USA.com
  • To: AndrewWatt2000@aol.com, xml-dev@lists.xml.org
  • Date: Thu, 05 Oct 2000 10:17:27 -0400

Title: RE: The failure to communicate XML - and its costs to e-business

On 10/5/00, AndrewWatt2000 wrote:

> If XML ever was "simple", can it seriously be suggested
> that that remains true after the addition of SMIL, XSLT,
> XPath, RDF and XHTML and the soon emergence of SVG, XPointer,
> SMIL 2.0, SMIL Animation, CC/PP, Canonical XML, XML Digital
> Signatures etc?

I just re-read the XML specification, and I didn't see any of these things mentioned. I can only conclude that none of these things have been added to XML.

SMIL, SVG, RDF serialization, and XHTML are *applications* of XML. You can do cool things with XML, but the cool things you do with XML don't automatically become part of XML. I can write an operating system in C++, but that doesn't mean that C++ includes an operating system.

XSLT is a transformation language for XML, which is also written in XML. I find XSLT very useful, and even fairly simple with the right documentation, but the fact that it exists does not make XML more complex.

So *please* do not tell the e-business community that these are all part of XML, because some of those people seem inclined to believe it. On the other hand, it's not a bad idea to tell these e-business people that there are a lot of tools for people who work with XML, that they can

learn from what others have already done with XML, etc.

> XML is not, for the vast majority of humankind, a "simple"
> format although it may be for some.

XML is not simple for most people to type by hand, but that's not what it was designed for. It is very easy to create XML with programs, and it is much easier to parse XML files than to parse proprietary data formats.

> XML on its own does, essentially, nothing.

In other words, it is declarative. It describes the structure, without telling you what to do with the data.

> Let's add the approximately 90 pages of the XSLT
> Recommendation to express our XML as HTML or XHTML.
> Then we can add the 500 pages of the XSL-FO draft
> if we want the potential advantages of Web and paper
> output from the same source data. And if we want to
> illustrate our pages with Scalable Vector Graphics (SVG)
> images we can add another 492 pages of reading. But, let's
> not forget that SVG has dependencies on Cascading StyleSheets,
> CSS, has a variant Document Object Model, and is
> dependent on the SMIL Animation drafts for animation,
> which in turn has dependencies on the SMIL 1.0
> Recommendation and the SMIL 2.0 Working Draft.

I'm confused. I thought you were writing primarily about e-business, and I find most of the technologies you mentioned in that paragraph irrelevant for e-business. I think that one of the big things we need to do is to help people focus on the core technologies, and help them ignore the others.

If I am trying to do transactions among businesses, I probably don't care about HTML, XHTML, XSL-FO, SVG, CSS, or SMIL Animation. I do care very much about XSLT - and I would recommend people use the excellent documentation found with SAXON, which is easier to learn from than the XSLT specification. There are also many useful tutorials on the Web. I would also strongly recommend that people learn SAX and DOM, and perhaps some form of Java data binding.

Jonathan





 

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

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