Subject: atom, xslt processors (Re: atom:type, xsl:output)

From: James Cerra <[email-masked]>
Date: Fri, 27 May 2005 18:54:15 -0700 (PDT)

Aristotle, Henri Sivonen,

> > > Entities can be flattened.
> > 
> > Again, as with comments, I agree in principle, but in practice
> > some processors depend on them.
> 
> I do not consider it at all wise to legislate anything in the
> Atom spec to address these cases.

That's probably a good idea.

> 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:

(1) The first stage of an Atom processor will probably be an XML processor.

(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.

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

An example of an IO processor is an HTTP processor: it reads Atom documents. 
An example of a PI processor is an XSLT processor or CSS renderer.  Forcing the
Atom Processor to be first is practically impossible and counter to the reason
for writing generic processors for IO, XML or PIs at all.

--
Jimmy Cerra
https://nemo.dev.java.net

__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

---

From: Henri Sivonen <[email-masked]>
Date: Sat, 28 May 2005 11:45:06 +0300

> <?xml-stylesheet?> processor,

A conforming xml-stylesheet processor will only act on the PI if it 
appears in the prolog. For this reason, it would be possible to allow 
xml-stylesheet PIs in atom:content and spec that they are part of the 
content document, so that an XML document with the PI in its prolog 
could be constructed from the content.

> (except for specific instances that don't matter here).

Perhaps it follows that you should not use xml-stylesheet if you don't 
want it to be acted upon.

> So any <?xml-stylesheet"?> nodes, and PI nodes in general, must be 
> assumed to be
> linked to the document as a whole;

Only if the PI appears in the prolog.

> Instead, they could be reported to the PI processor before the atom 

Why do you think it is appropriate to have a random PI processor in 
between the XML processor and the Atom processor?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 28 May 2005 11:59:55 +0200

* James Cerra <[email-masked]> [2005-05-28 04:00]:
> > 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.

> > 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

---

From: James Cerra <[email-masked]>
Date: Sun, 29 May 2005 16:47:54 -0700 (PDT)

Henri Sivonen,

> could be constructed from the content.

You are correct.  I forgot that part of the spec and should have re-read it.

One possible area of incompatibility is where the xml-stylesheet spec says that
they are only allowed in the prolog (as you stated as well).  So if any are in
the application/xml atom:content, then they could be flagged as errors.  The
spec doesn't say whether they must or should be considered errors or warnings. 
:-(

> between the XML processor and the Atom processor?

Because the XML is just the grammar serializing the ontology, or data
structure, of interest.  I see Atom processors as normally the Bridge between
the XML document and the particular CMS, IA, or web browser application's
internal structure.  So an Atom processor would be the last stage before the
data is internalized.  The intent of _Processing_ Instructions seems to change
how the document is processed.  That implies to me that they would probably be
interpreted between the XML processor and the particular grammar's processor.

---

From: James Cerra <[email-masked]>
Date: Sun, 29 May 2005 17:24:40 -0700 (PDT)

Aristotle,

> 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.

> 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.

		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 30 May 2005 16:54:23 +0200

* James Cerra <[email-masked]> [2005-05-30 02:00]:
> > Why do you think it is appropriate to have a random PI
> > processor in between the XML processor and the Atom
> > processor?
> 
> Because the XML is just the grammar serializing the ontology,
> or data structure, of interest. I see Atom processors as
> normally the Bridge between the XML document and the particular
> CMS, IA, or web browser application's internal structure. So
> an Atom processor would be the last stage before the data is
> internalized. The intent of _Processing_ Instructions seems to
> change how the document is processed. That implies to me that
> they would probably be interpreted between the XML processor
> and the particular grammar's processor.

Atom is a transport envelope for potentially a multitude of
documents. Saying that the enveloped documents should be
preprocessed before they are unfolded from the envelope is like
saying that a part of a multipart/mime document which has a
“Content-Encoding: gzip” header should be uncompressed in situ
*before* it is extracted from the multipart envelope.

That doesn’t make any sense.

Regards,
-- 
Aristotle

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 30 May 2005 17:02:53 +0200

* James Cerra <[email-masked]> [2005-05-30 02:35]:
> 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.

So you expect every XML processor to have an XSLT processor
attached so that it will be able to resolve your custom Atom+PIs
superformat to regular Atom?

Regards,
-- 
Aristotle

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 May 2005 09:10:47 -0700

At 4:54 PM +0200 5/30/05, A. Pagaltzis wrote:
>"Content-Encoding: gzip" header should be uncompressed in situ
>That doesn't make any sense.

+1

--Paul Hoffman, Director
--Internet Mail Consortium