RE: xml-stylesheet p.i. and other options
Mike, Hey don't worry. I don't think anyone is having a go at you. Just discussing. I disagree with you but we can do that on this list without anyone getting the hump. I think pi's are the way to go because they are hints to the application on how it should process the data. I agree that there could be a lot better framework to handle all of theese multiple file situations but we don't have one. For schema they use schemaLocation which does adulterate the xml whereas a pi is just a hint and comes in the preamble before the data proper. Ciao Chris XML/XSL Portal http://www.bayes.co.uk/xml > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Brown > Sent: 26 June 2002 11:02 > To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx' > Subject: Re: xml-stylesheet p.i. and other options > > > 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 > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format