- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 14 May 2002 14:38:55 +0100
- To: Eric van der Vlist <vdv@dyomedea.com>
- CC: xmlschema-dev@w3.org
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