Re: <length> = a real number plus a unit qualification

Hi Eric,

> I feel always very uncomfortable dictating design rules based on
> tools support: in many cases, tools change faster than markup and
> some rules which were considered as good practice because of DTD
> restrictions are now obsolete. I think (and hope) that this will be
> the case later or sooner with rules dictated by W3C XML Schema 1.0
> or XPath 1.0 or any other specification which is not "core XML".

Good points. On the other hand, it seems foolish to completely ignore
the impact that the design a markup language might have on the kind of
processing it enables you to do with the information represented by
it. Take the example that came up the other day:

  <list>
    <item1>...</item1>
    <item2>...</item2>
    <item3>...</item3>
    <item4>...</item4>
    ...
  </list>

Or the design that sends shivers down every XSLT author's back:

  <result><![CDATA[<record>...</record>]]></result>

While it's true that in the future, schemas might be able to
articulate rules that say that element names have to start with a
certain string and end with an incrementing number, and that XPath
might have a function that parses XML and returns the tree, it's a bit
unwise to create a markup language that you want to validate against
XML Schema and want to transform with XSLT, but incorporate things
that can't be processed with them.

As always, there's a balance to be made. The annoying thing is when
something is common practice in markup languages, but doesn't end up
being supported by something that is supposed to help process XML;
assuming that coverage of existing practice was a goal, that's the
fault of the tool, not the markup language design.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Tuesday, 14 May 2002 09:38:56 UTC