best markup practices, different communities

["Simon St.Laurent" <simonstl@simonstl.com>]

After spending ten days on a cruise ship presenting and discussing XML, I'm
starting to have some serious doubts about what XML brings to developers in
various communities.

The doubts are not about the value of markup itself, or the enormous
possibilities opened up by cleanly labeled structured documents.  Markup
itself, Ted Nelson's doubts aside, has proven to be remarkably powerful and
useful stuff.  Reusable tools are great for lazy programmers (that's a
compliment!), no doubt.

What I am worried about is a lot of the best practices that inform the
creation of XML standards and XML documents.  The large-scale publishing
experience that informs what I typically refer to as 'XML best practices'
doesn't seem an appropriate influence on other applications of markup.

There are plenty of cases where I sincerely doubt there is 'one true way'
for document, data, and Web folk - these different fields have different
technical requirements for information handling, some of which overlap in
odd ways.  

Separating content from presentation makes an enormous amount of sense if
you're publishing content to multiple media targets or designing relational
database tables,  but very little sense if you're creating user interfaces
which need to contain some logic in the markup used to define them - DHTML,
XUL, etc.  (I find it ironic that the Web community could probably benefit
most from processing instructions, but the World Wide Web Consortium openly
discourages their use.)

Mixed content is critical to both document and Web developers, since both
spend so much time working with the messy structures that humans tend to
create, but can be a huge nuisance for data-oriented developers who wonder
why the document folks are too lazy to add the extra markup necessary to
avoid the need for mixed content in the first place.

The '&' model, which works extremely well for database recordsets and is
effectively used every day all day in a wide variety of application, has
somewhat catastrophic problems when introduced to the rest of the XML
grammar, and was therefore excluded.  Data-oriented developers now get to
worry about sequence on a much more regular basis.

I'd also suggest that project scale plays a substantial role in best
practices, and that smaller projects may need fewer but sometimes more
tools to make them work as their developers would like.  Enormous technical
documentation projects and small-scale hypertext poetry can both make
effective use of markup, but I'm not sure that the requirements above and
beyond cleanly structured labeled content are substantially similar.

Tim Bray just wrote:
> So I say to you all: go back in your caves and come out with 
> *one* schema facility that lets me write grammars when I want 
> to and xpath expressions when I want to, and has an elegantly 
> unified syntax.  Then declare victory.  For extra credit, 
> replace entities too (just kidding).  -Tim

I think it's time to give up on the dream of a single facility for all of
that, and start focusing more on best practices which are appropriate to
particular communities.  Think about allowable subsets of functionality
rather than demanding the 'there can be only one' approach, and standardize
only where it's both possible and relatively easy.

XML 1.0 standardized the 'relatively easy' stuff for markup itself, though
I wish more and more that DTDs had been defined in a separate document.
I'm not convinced that we can find nearly as much uniformity of purpose at
any level beyond the foundation.

I do have hope that we can do interesting things, however - I was impressed
recently to see Murata Makoto defining a separate set of rules for
processing data-oriented information using RELAX than the document-oriented
rules of RELAX Core.  It's an interesting approach to using different sets
of rules, which can be used in a common processing environment while
preserving the understanding of different contexts.:
http://www.egroups.com/message/reldeve/207

Something like that, rather than solving all problems with a single set of
tools, seems like a less combative and potentially more extensible
approach.  Assuming that a single solution is possible by merely separating
the technical from the political seems to me like a recipe for unrewarding
collisions and pileups over the next few years.

Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books