Re: [xsl] Saxon for XMetal

Subject: Re: [xsl] Saxon for XMetal
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 06 Jun 2005 01:06:25 -0400
Mike,

Although it's theoretically possible to code XSLT with XMetaL, one wouldn't ordinarily do this.

The main reason for this is that, as a structured editor, XMetaL is dependent on a DTD (or schema) to inform it of legal document structures for a given instance.

There is no DTD for XSLT, and there really can't be, since any stylesheet may contain arbitrary literal result elements, which means a DTD for XSLT would have to include all possible XML elements, in all possible arrangements. Since XML element (and attribute) names are not limited in length, this is an unbounded set.

A partial DTD for XSLT 1.0, in which LREs are not accounted for except by placeholders, is actually available (published as an appendix to the spec), although non-normative. On this basis it might conceivably be possible to write a DTD to describe, say, XSLT stylesheets that generate HTML. (Or alternatively, one might prohibit LREs in one's stylesheets and use only xsl:element and xsl:attribute instructions for generating nodes. I have even seen this approach taken with Emacs, though not recently, since we have had decent tools including XSLT IDEs for Emacs.) But even this would be a poor fit, since the semantics expressible in DTDs do not cover the actual constraints over XSLT. For example, a DTD by itself could not tell the difference between an XPath expression and just any string, in an XSLT "select" attribute value. A stylesheet containing an illegal XPath expression is formally not XSLT at all, since it can't be compiled. But DTD validation on its own can't distinguish this class of documents from actual stylesheets.

Current versions of XMetaL also support schema validation in lieu of DTDs, but the same problems apply there -- not as severely, but to the same practical effect.

What all this argues is that XSLT not be considered to be just any XML document, usefully editable by any XML editor. (Even if this can be done in a pinch: and indeed, XMetaL does have a "well-formed only" mode, though this is not its strength.)

Accordingly, we have a healthy market for tools, such as oXygen (which Bruce mentioned), ActiveState Komodo or XMLSpy. Given how much of a range of choices one has here (including at the free end), using XMetaL would seem rather, um, twisted. Like baking a cake in a fireplace. It can be done, sort of: but it's much much easier in a proper oven.

Cheers,
Wendell

At 01:32 PM 6/3/2005, you wrote:
Friends,
I was recently asked about using XMetal with XSLT.

I don't use XMetal.

However, maybe there are some out there that could give me the
low-down on the good, bad or ugly XSLT "features".


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread