On May 28, 2005, at 05:28, James Cerra wrote:
Henri Sivonen,
Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still
inappropriately
use comments for that purpose.
I am not familiar with that. What purpose exactly? Why should Atom
support it?
MSIE conditional comments. See other
On May 28, 2005, at 04:54, James Cerra wrote:
Aristotle, Henri Sivonen,
Yes, but any Atom document MUST be processable from just an XML
processor, an
?xml-stylesheet? processor,
A conforming xml-stylesheet processor will only act on the PI if it
appears in the prolog. For this reason,
Tuesday, May 24, 2005, 5:26:39 PM, you wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
An Atom Entry can have XML content, right...
Consider this example:
feed xmlns=http://...atom;
...
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
...
* 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
James Cerra wrote:
So do I. That's why the spec should state that any XML fragments embedded into
atom:content as an XML tree become part of that tree. So PIs become associated
with the Atom document rather than the content, for example. If the entry MUST
be preserved unmodified (Author's
* Eric Scheid [EMAIL PROTECTED] [2005-05-28 11:00]:
An Atom Entry can have XML content, right...
Consider this example:
Entirely legal, but who wants to bet the feed validator throws
a fit ;-)
Most aggregators will probably ignore the content, and likely not
even do anything useful with
David Powell wrote:
IF, the interpretation of Section 6, that Thomas Broyer has helped me
to hammered out is correct, then:
Extension Elements [6.4], in Atom 1.0, are allowed only as direct
children of atom:entry, atom:feed, Person Constructs, and atom:source.
They must be qualified with a
Eric Scheid wrote:
An Atom Entry can have XML content, right...
Consider this example:
feed xmlns=http://...atom;
...
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
Eric Scheid wrote:
An Atom Entry can have XML content, right...
Consider this example:
feed xmlns=http://...atom;
...
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
On May 28, 2005, at 2:09 PM, John Panzer wrote:
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
...
/entry
Or perhaps:
feed
At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
The Key Info is part of the XMLDigSig, but it is not required. Because
it tells you where and how to obtain the pertinent certificate, it
could be a boon for this particular application. There is no need
to keep the signer
On Sat, 28 May 2005 at 14:01:56 -0700 Paul Hoffman opined:
At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
The Key Info is part of the XMLDigSig, but it is not required. Because
it tells you where and how to obtain the pertinent certificate, it
could be a boon for this
13 matches
Mail list logo
