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