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

Re: xml-stylesheet p.i. and other options

Subject: Re: xml-stylesheet p.i. and other options
From: Mike Brown <mike@xxxxxxxx>
Date: Wed, 26 Jun 2002 04:01:36 -0600 (MDT)
xml stylesheet pi
David Carlisle wrote:
> > such as when you've got no problem with the fact that your PIs
> > might be ignored -
> 
> Not agreed. saying that an application might ignore a PI is like saying
> that an application may ignore <security level="top secret"> and publish
> the information on the web. It's true, whatever the syntax is used,
> elements, PIs lisp, ... it requires applications that read the syntax
> and implement the specification of that syntax.

Definitely not agreed.

1. An application is not required to take action on any
processing instruction. The XML spec only requires that the application be
made aware of the instruction's existence.

"PIs are not part of the document's character data, but must be passed through 
to the application. The PI begins with a target (PITarget) used to identify 
the application to which the instruction is directed."

(It is also suggested that you should use a Notation name as the target, so
that your PI is essentially able to reference an application by a URI through
that name)

It is reasonable to infer from this that it is not even a requirement for
an application to care about xml-stylesheet or any other target that it 
doesn't recognize.

2. The semantics of the xml-stylesheet PI are that there is an association
made between the XML document containing the PI and the referenced stylesheet,
nothing more. There's no requirement that an application processing the XML
divine the intent behind the association, or take action upon it. So even if 
you feel that (1) is not true and that a PI can't be ignored, honoring the
xml-stylesheet PI is pretty much a no-op, if the application wants it to be.

> >  when they're being applied to tie data to business logic; 
> > aapplications shouldn't be forced to fit the PI model.
> 
> so business applications shouldn't specify their input using say dtd or
> schema either both of which are only optionally read by a minimal XML
> application (which needn't implement XSLT either).

I don't follow exactly, but I think you're comparing apples and oranges.  No,
it's not harmful, but my argument can be applied here as well. 

I as the XML document author "shouldn't" assume, just because I've referenced
a DTD or schema, that my application will receive validated input from the
parser! Yet that's what I want/expect, so I've effectively imposed a
requirement on the application developer to ensure that the application only
gets its input from a validating parser.

Even so, if I reference an external DTD or an XML Schema in my XML document,
it does indeed come with a risk that it won't be processed (didn't someone
recently say that Mozilla isn't reading external entities?), so I have to take
that into account when I write my application. I certainly can't expect that 
my XML document will dictate that the application be smart enough to use a 
validating parser or a parser that resolves external entities.

> Accepted that a lot of XML travels over the web in machine to machine
> communication, for serving of XML over the web to browsers for human
> consumption, I'd say the PI is currently the only option available.
> (There are other options, such as server side transformation, but tehy
> don't involve serving XML over the web)

Those other options often do involve an HTML user-agent requesting XML,
though, and getting back HTML. So while raw XML wasn't served, XML was
requested, and a server-side application decided that the request should be
interpreted as a request for the data within that XML, formatted in a manner
more appropriate for that particular client. As I keep trying to say, this
kind of decision and the determinations that go along with it (such as what
the client's capabilities are and what an appropriate transformation would be,
if any) is for the application to make. These needs are not very well-met by
the PI approach at all.

<sourGrapes>

I'm very sorry I pushed this thread in this direction. I feel
that I made the same statement as Michael Kay has made on the list more than
once, even very recently -- that the xml-stylesheet PI and the paradigm it
currently imposes (which is highly dependent on assumptions made about what
clients will do) was generally not a good way to isolate data from
presentation.

Wendell Piez didn't disagree but challenged me to summarize what some of the
alternatives were, so I started to list them but kept getting caught up in
trying to (over-)explain under what circumstances you'd want to use those
options. I finally posted my take on the situation, my rationale for believing
xml-stylesheet is harmful, and why I felt so strongly about it. My rationale
may not be the same as M.H.Kay's, but it led me to approximately the same
conclusion. Yet now I have nary a sympathetic ear, and Kay hasn't offered his
2 cents at all, so I look like an idiot and a troll.

</sourGrapes>

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.