At 03:56 AM 9/27/2005, you wrote:
> > I'm a bit mystified because what you say above suggests you have set
> > <xsl:strip-space elements="*"/>
> > which is not necessary.
>*I* don't, but I've seen a lot of users trying it that way.
Ah, so this is an argument for catering to ignorance? (It's okay if
it is; sometimes this is necessary.)
> > If you have a schema (or even if you don't, but know what the schema
> > would tell you), it's not hard to say
> > <xsl:strip-space elements="TEI.2 body div"/>
> > where TEI.2, body and div are those elements in your schema defined
> > as having element-only content. This way you can safely dispose of
> > whitespace-only nodes that are there only for cosmetic reasons in the
> > code, while safely leaving in place any whitespace that might matter.
> > What's so hard about that?
>Nothing, except that when you are dealing with a very wide range of DTDs
>and Schemas, it would be more useful if the work of determining where
>element content occurs were done by the parser (which already knows,
>dammit! because it's just read the DTD!) than to make the users work it
>out for themselfs.
I think this is a tradeoff. Sometimes you want the tool just to "do
the right thing". Sometimes you want more of an informed choice by
the user. The latter, especially when "the right thing" has grey
boundary lines (or is grey altogether). I'm not convinced that I (or
"we") would be happier with a new schema dependency in XSLT
processing. (I've stopped defaulting attributes entirely as I've
shifted to more powerful, flexible and expressive schema regimens,
such as RelaxNG+Schematron.)
>It's really down to usability: XML changed the document model from SGML
>(in most cases, in the right direction) but this was one area we fouled
>up in. No biggie, but the concentration on "data" use of XML has meant
>that the needs of "document" usage have largely been set aside.
> > Respectfully, while I understand why you want XML tools to do a
> > better job at what-was-once-intended-for-SGML tools,
>My users want XML to at least do *as good a job* as SGML did. In this
>respect XML is falling down.
Again, depends on where you sit. Most of "my users" (I know lots of
users at all levels from all sectors) don't have any basis for
comparison to SGML, but I can sure see they're benefiting from, e.g.,
the huge range of XML tools that SGML never had. There are many
reasons for the existence of this toolkit; but I think XML's cleaner
layering between instance and schema is one of them.
> > I don't think
> > any other suggestion gets anywhere close to the right balance. In
> > particular, I do not think it would be a net gain if we had another
> > area where a document processed with a schema gives different results
> > from the same document processed without a schema. If your schema has
> > the effect of modifying your data when it is processed, IMO it should
> > be a transform. ;->
>Then the transformation language should provide the facility to do it
>right. XSLT does not at the moment provide this, AFAIK, because it
>removes those white-space nodes in mixed content which should only be
>compressed to a single space instead. It is precisely the transform
>which is modifying the data, not the schema or the parse.
Could you specify your requirement for munging again? Could it be
done as a function munging text nodes? (But I'm afraid I won't be
able to get back to the list for a few days....)
I've got whitespace cleanup stylesheets to help me when I really need
them. But I haven't taken the time to try to generalize them. A
generalized solution might want to take more than one pass, if it's
to use a really simple algorithm.
It sounds like an Extreme paper, Peter.
And all of this is thankfully beside the original question, the right
answer to which depends on much more than whether XSLT happens to be
"good enough" in this respect.
Wendell Piez mailto:[log in to unmask]
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