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: "Simon St.Laurent" <simonstl@simonstl.com>
  • To: xml-dev@lists.xml.org
  • Date: Thu, 05 Oct 2000 11:04:24 -0400

At 09:52 AM 10/5/00 -0400, David Megginson wrote:
>Richard Lanyon writes:
>
> > The question is, how much of the XML-associated technologies do you
> > /need/ in order to be able to start working on XML?
>
>My advice to a new XML user would be to learn XML 1.0 itself, XML
>Namespaces, and (if she's a coder) at least one of the XML-related
>APIs.  A glance at a Unicode tutorial might be a good idea as well.

I'm pushing people toward Common XML core as a foundation:
http://www.simonstl.com/articles/cxmlspec.txt

(Okay, all right, I edited that document, with much help from SML-DEV.)

Now I just need to write a tutorial for Common XML instead of a spec.

One of the things I've really enjoyed about the Common XML work is that
it's refocused me on the core of XML, the parts people really use on a
regular basis, and pulled me away from the delicious 'how do I build
compound element names using parameter entities without introducing a space
in the middle of the name' questions.

Beyond that core of elements, attributes, and simple namespaces, it seems
things really diverge.  Some people want nothing to do with DTDs, planning
to move directly to Schemas (or even RELAX).  Others don't care about
either DTDs or Schemas.  Some folks can get their work done with SAX alone,
while others use just the DOM and others need SAX, DOM, and XSLT working
together, and then maybe they switch to JDOM from DOM and...

Hypertext people need XLink and/or RDF and/or Topic Maps, while programmers
might be more interested in SOAP, XML-RPC, or some other protocol or
messaging work.

The bifurcations are downright incredible - but we can all happily share a
relatively small core.

>After that, she should ignore the other specs until she has a serious
>problem that she cannot easily solve otherwise; if she never ends up
>reading RDF, SMIL, DOM, SAX, XML Schemas, XLink, XPointer, XSLT, SOAP,
>RSS, CSS, XHTML, XHTML modules, etc., then she didn't need them in the
>first place.

Yep.  Giving people a map to the specs they might need someday seems wiser
than teaching them the details.

>On the other hand, if she reads these specs too early, she'll just end
>up inventing problems for the solutions she's learned.  Part of my
>consulting work is cleaning up after people like that.

Mine too, though (because I write largely beginner books) I tend to get
people early enough to tell them not to go ahead instead of cleaning up.
Less lucrative, but it feels good.

>The only so-called XML-related W3C specs my customers have used so far
>in real production systems (as far as I remember) are XML itself,
>Namespaces, RDF (really!), XSLT, and XPointer (only through XSLT,
>though).  I've heard of others using the DOM, though DOM
>implementations seem to run into trouble in high-demand environments.
>In all cases, the customers used each W3C spec because (a) it solved a
>real problem that they would otherwise have had to invent a new
>solution for, and (b) there was available software support.

I'm with David on the reality check, though I see more XHTML (mostly for
the hell of it) and DOM use.  I don't see much XPointer - just XPath.  And
yes, I do see some 'real' RDF work out there.
 
Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books




 

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

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