[XSL-LIST Mailing List Archive Home]
Re: [xsl] Saxon for XMetal
Subject: Re: [xsl] Saxon for XMetal|
From: Mike Ferrando <mikeferrando@xxxxxxxxx>
Date: Mon, 6 Jun 2005 09:38:29 -0700 (PDT)
Thanks much for your detailed info.
I will pass this on to my friend.
Library of Congress
--- Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:
> Although it's theoretically possible to code XSLT with XMetaL, one
> 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
> for a given instance.
> There is no DTD for XSLT, and there really can't be, since any
> 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.
> alternatively, one might prohibit LREs in one's stylesheets and use
> xsl:element and xsl:attribute instructions for generating nodes. I
> even seen this approach taken with Emacs, though not recently,
> since we
> have had decent tools including XSLT IDEs for Emacs.) But even this
> be a poor fit, since the semantics expressible in DTDs do not cover
> 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
> Current versions of XMetaL also support schema validation in lieu
> of DTDs,
> but the same problems apply there -- not as severely, but to the
> practical effect.
> What all this argues is that XSLT not be considered to be just any
> 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,
> this is not its strength.)
> Accordingly, we have a healthy market for tools, such as oXygen
> Bruce mentioned), ActiveState Komodo or XMLSpy. Given how much of a
> of choices one has here (including at the free end), using XMetaL
> seem rather, um, twisted. Like baking a cake in a fireplace. It can
> done, sort of: but it's much much easier in a proper oven.
> At 01:32 PM 6/3/2005, you wrote:
> >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
> Mulberry Technologies, Inc.
> 17 West Jefferson Street Direct Phone:
> Suite 207 Phone:
> Rockville, MD 20850 Fax:
> Mulberry Technologies: A Consultancy Specializing in SGML and
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around