Well, as a guy that has done a lot of work in software systems design and in data processing architecture my humble opinion is that you should look at the XML model as in some ways parallel to an OO system.
In OO methodology you would want to subclass. In other words the problem with the inappropriate PI in your document is very similar to the problem in an OO system where you have a class which doesn't provide the interface you need. So you subclass it. This is very much equivalent to the concept of applying different stylesheets in XML. The fact that the people that defined XML in the beginning called PIs "hints" is irrelevant. XML processing has grown far beyond what was originally envisioned. That terminology and method of thought originated in the world of document management and styling, not application type processing. Think of PIs as essentially "class declarations", the PI defines the CODE that is associated with the data represented by the XML document instance. If the same data needed to be processed in different ways in an OO system, you would instantiate different classes or subclasses for that purpose, so in XML land you would use different sets of PIs. If you want to have an XML document that represents data for processing, as opposed to data for presentation, you really shouldn't be using PIs embedded in the data, you should be getting your processing instructions from the request (think of it like "method call") instead. All that being said I see nothing wrong with being able to override a PI, but in effect its a kludge which should be resorted to only if you can't do what you need to do in other ways. If your getting data from external systems and it comes with PIs attached then they should be stripped out with XSLT. In many cases you would want to process that information and transform it anyhow, so in most instances that isn't really a big deal. As a plus XML gives us the option to use "alternate stylesheets" which we can think of as a mechanism for providing a sort of "overloading" of certain operations when appropriate. There is no exact equivalent in an OO system paradigm, but in some ways it is much like in OO perl where you can bless the same fundamental data type into one or more different packages depending on your needs. On Monday 21 January 2002 17:12, you wrote: > On Mon, Jan 21, 2002 at 11:33:24AM -0500, Tod Harter wrote: > > Isn't the answer then to NOT have the PI in the original data? I mean if > > you sometimes need it and sometimes don't then the stylesheet isn't > > really PART of the document > > this is rather a council of perfection, isnt it? in practice: > > document, so the processing chain should provide that information... In > > other words your base document stored on disk should NOT contain the PI, > > instead the request for the document should somehow specify what > > stylesheet to use. > > but when the "request for the document" == "loading it into Opera", then > its a damned-site easier to have that PI in there. > > A PI is, after all, a *hint* to a processor, which the processor > may choose to ignore. All we want is to have AxKit configurable about > whether or not it implements that PI instruction > > > PI's in documents should only be present when they are ALWAYS relevant. > > um, I beg to disagree. that was NOT the way PIs were defined > way back when. they are optional hints to whoever wants to read them. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
