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
======================================================================