Aristotle, > > (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.
Note that I was wrong about <?xml-stylesheet?> though I still believe the property holds for PIs in general. I think that *all* PIs in the XML document should be considered readable - and therefor dangerous - before the Atom processor does its magic of informing the application about the feed's ontology. Letting ONLY escaped (either into strings or with base64 encoding) content of atom:content, or documents linked via @href, is one way to allow literal, complete XML documents as content (and not just XML fragments). This gives them the same treatment as any non-XML content like images or sounds. OTOH for XML fragments, I think it would be nice to allow the content to be a child of atom:content, as currently possible. > > 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. I disagree. I see any XML application conceptually as a transformer from the XML processor's trees or events to the internal data structure of the application. To use an analogy, I see an XML processor as a lexer and the grammar's processor as the parser - substituting tokens for XML objects (i.e. elements with names, attributes, children, base uri, etc.). XSLT is a case when the grammar's processor's output are XML objects that can be parsed by another grammar's processor without having to use an XML processor. So I see an Atom processor as taking XML objects and producing an ontology to be converted into the program's internal data structure. This is the abstraction I use; practically the details are usually different (though compatible with that abstraction). For a counter example: For internal use I might create an Atom feed from atom entries with <?xml-stylesheet?> attached to either the feed or the entries. Furthermore, I could add instructions for my stylesheet by defining PIs used in the entries. In this case, the PI processor is an xslt processor that works before the atom processor. The original contains global options and defines the template, while the entries are parsed and aggregated into the original file. This way it is easier to change the feed's options without editing the XSLT source files. The atom processor becomes the last stage in the pipe. -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
