[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: I can XInclude where I bloody want to

• To: xml-dev@l...
• Subject: Re: Re: I can XInclude where I bloody want to
• From: Mike Brown <mike@s...>
• Date: Thu, 2 May 2002 13:05:19 -0600 (MDT)
• In-reply-to: <003101c1f1c6$a5c42b80$6501a8c0@pcukmka> "from Michael Kay at May2, 2002 11:46:41 am"

Michael Kay wrote:
> > > I just keep thinking back to MSXML and whitespace, though.
> >
> > I disagree. This is a near fatal blow to using IE as an XML document
> > browser.
> 
> It's not totally fatal, because by writing enough scripting code in an HTML
> page you can force it to do the correct thing and preserve the spaces.

That's what I was getting at...

The situation today is that we end up having to say "Tested / designed to work
with Acme XSLT 0.0.01-BETA, because it supports XInclude pre-processing and
d-o-e and it has some extension functions we like", just like web pages used
to say "Optimized for Netscape". <shudder/>

I agree that the differences between XSLT processors effectively encourage
coding to specific processors, just like the spate of hideous HTML that
dominated the web during that Netscape's heyday. But my stance on how terrible
of a thing this situation is has softened a bit over the years, especially
after seeing the Netscape browser's fall from grace.

As much as we engineers appreciate clean, universal, low-maintenance code,
code, be it XSLT or XIncludes or HTML or what have you, is ultimately a means
to an end, and to a large extent, people writing the code just want It to
Work. They want to be immediately productive and they want the path of least
resistance. In a typical Internet product having a 2, maybe 3 year lifespan
(tops), being married to a particular XSLT processor or popular browser family
is a small price to pay for achieving that end. It's a sad reality, from an
engineering standpoint, but one that is partly responsible for rapid adoption
of and general success of the technologies.

We engineers and architects of these new technologies strive to make
interdependencies as avoidable or painless to dissolve as possible, and I'd
say the current family of XML standards do an admirable job in this regard.
But the reality is that we're not There yet, and although we should stay the
course, we don't need to get bent out of shape about things like XSLT
processors honoring XIncludes -- especially when these violations are of
assumptions about what seems right, versus what has actually been specified.
The marketplace will bear out the wisdom of these decisions in a pretty short
span of time. In the mean time, we'll all have jobs[*] fixing and figuring
these things out. :)

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/
                                     ^^^^^^
                                     [*] I'm looking for work, actually.

• References:
  • RE: Re: I can XInclude where I bloody want to
    • From: "Michael Kay" <michael.h.kay@n...>

• Prev by Date: RE: SOAP and the Web
• Next by Date: RE: SOAP and the Web
• Previous by thread: Re: Re: white space transformations (was xinclude)
• Next by thread: RE: Re: I can XInclude where I bloody want to
• Index(es):
  • Date
  • Thread