* James Cerra <[EMAIL PROTECTED]> [2005-05-28 04:00]: > > Nothing prevents anyone from writing a generator or pre- or > > postprocessor for Atom documents to cater to the needs of > > their particular brand of broken software. Wrangling that > > particular piece of broken software however is their job; not > > ours nor the Atom specs. > > Yes, but any Atom document MUST be processable from just an XML > processor, an <?xml-stylesheet?> processor, among other specs > it uses, and possiblely produce something that can be > transformed Atom's processing model allows. This is because:
Note that I wrote the above in reference to broken software that depends on particular entities vs the literal character or on specific comments, not in reference to PIs. That’s why I quoted that part of the previous conversation which I quoted. > (2) RSS and Atom documents are now processed with > <?xml-stylesheet?> PIs, and there is no way to formally specify > when those instructions should be executed (except for specific > instances that don't matter here). So any <?xml-stylesheet"?> > nodes, and PI nodes in general, must be assumed to be linked to > the document as a whole; I know of no standard granularity > mechanism. I agree, but I see this as a problem with the xml-stylesheet PI rather than as something that Atom must solve. You are right, of course, that it would be prudent for the spec to legislate that PIs which occur in atom:content with an XML payload should be passed thru to the processor for that XML payload. Btw, it might well be that the practice of attaching a stylesheet goes out of fashion again in a year or two, if other browsers follow Safari’s lead and acquire feed rendering capabilities. > That's one reason the following is not true: > > > Vanilla XML processors don't act on PIs. They report them to > > the application--in this case the Atom processor. > > Instead, they could be reported to the PI processor before the > atom processor. In my mind, any Atom processor (or any > language-specific processor) has to sit on top of several other > ones: > > IO Processor > XML Processor > PI Processors > Atom Processor I disagree. The typical setup, IMO, would be 1. IO Processor 2. XML Processor 3. Atom Processor 4a. Possibly a processor for that specific XML NS 4b. Possibly a PI Processor where 4a might or might not itself act on specific PIs. F.ex, I would expect that an Atom processor will disregard an xml-stylesheet PI attached to a feed as a whole. But it might apply an XSL transformation if it is told to process a document which is not an Atom feed – under the assumption that this transform might generate a valid feed document. That’s still murky (and I have to go read up on xml-stylesheet in detail to see how much room for interpretation it allows), but all of this seems to indicate to me it’s that the semantics of that particular PI which are ill thoughtout, rather than a general problem with PI granularity. Regards, -- Aristotle
