Bill de hÓra wrote:
the problem is managing the stream buffer off the wire for a
protocol model that has no underlying concept of an octet frame.
I've written enough XMPP code to understand why the BEEP/MIME crowd
might frown at it
Framing is, in fact, an exceptionally important
On Aug 23, 2005, at 07:27, A. Pagaltzis wrote:
I still dislike the idea of a “virtual closing tag” – it ain’t
1995 anymore, after all.
You seem to be thinking that an XML parser needs to consider the whole
document before reporting data to the app. This is not the case.
If you have a
Tim Bray wrote:
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a
unique API.
Ahh, I had thought this was a more dedicated ping traffic stream. The
* Tim Bray wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be
On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote:
* Martin Duerst [EMAIL PROTECTED] [2005-08-23 05:10]:
Well, modulo character encoding issues, that is. An FF will
look differently in UTF-16 than in ASCII-based encodings.
Depends on whether you specify a single encoding for all
--On August 23, 2005 9:40:44 AM +0300 Henri Sivonen [EMAIL PROTECTED] wrote:
There's nothing in the XML spec requiring the app to throw away the data
structures it has already built when the parser reports the error.
There is also nothing requiring it. It is optional. The only
reqired
On 23 Aug 2005, at 2:57 pm, Bjoern Hoehrmann wrote:
No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal
error. -Tim
Yes, exactly what I wrote...
the XML processor must report the error to the application and that the
processor is not required by the XML specification to
* Graham wrote:
the XML processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined
vs
Once a fatal error is detected,
On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional
On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote:
It's got another advantage. You connect and ask for the feed.
You get
feed xmlns=http://www.w3.org/2005/Atom;
... goes on forever
and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few
On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote:
If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and
I've updated the License and Expiration Extension Proposals to reflect
the recent discussion about metadata inheritance.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-02.txt
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-01.txt
The license draft
Le 05-08-21 à 11:45, Paul Hoffman a écrit :
At 12:17 AM +1000 8/22/05, Eric Scheid wrote:
#2 through #4 seem understandable, but what the heck is #1? The
place where this feed was put together? The place where this feed
was originally grabbed from?
hmmm really?
author
13 matches
Mail list logo
