Edward,
The reason we disparage d-o-e in applications like this is that it violates
a basic architectural principle of XSLT, namely that "tags" are the
business of parsers (which resolve tagged text into corresponding node
trees) and serializers (which write the information held in trees as tagged
text), not of the transformation itself.
The technique you're suggesting, "tag writing", is not evil in itself, but
since it relies on d-o-e, and since d-o-e allows you to violate the
architectural separation between transformation (which operates on a model
of an XML document) and control of the tags (which requires direct handling
of the syntax of XML) and is therefore optional for XSLT engines -- you'll
find any transformation that relies on it will not be portable.
For example, you'll find that although this works in IE (current versions),
it doesn't in Mozilla.
That's the immediate practical downside. Other potential downsides are that
(a) tag-writing code is more difficult to debug and maintain as problems
get complex (as Jay indicates, well-formed output is no longer
guaranteed!), (b) it can be a chore to integrate such a transformation into
larger frameworks (which often prefer to have parsing only happen once, in
front), and (c) (related) there may be performance issues as well (tag
writing and parsing requires overhead).
But as so often with this kind of thing, the answer is not an absolute "yes
it's fine" or "no never do it" -- the devil is in the details, and whether
you're in a situation where you can violate the rule without paying too
high a price ... can only be determined by taking a good look at your
overall processing environment and requirements, now and in the future.
Sometimes that's easy; sometimes it's difficult or impossible.
Accordingly, both to play it safe and so that learners can internalize the
easy mostly-true answer before having to come to grips with the
more-complicated-but-truer answer, whenever anyone suggests tag writing
with d-o-e we like to cry foul.
Cheers,
Wendell
At 02:26 PM 4/20/2005, you wrote:
> So, how else would you get the XSL
> transformation to ignore something like this?
The other way is to not ignore it and instead create a transformation to
deal with it.
> Is there a non-DOE way to do this?
The non-DOE way is how we solved it last week: grouping. That way, we meet
the requirement of well-formedness without resorting to DOE.
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--