James M Snell wrote:
We are proposing the creation of an Atom Reference Implementation
project at Apache and have donated source to kick things off. Currently
the source fully implements RFC4287 and includes preliminary support for
parsing APP introspection documents and the Feed Thread
James M Snell wrote:
We are proposing the creation of an Atom Reference Implementation
project at Apache and have donated source to kick things off.
What minimum Java version are you targetting? 1.2? 1.4? 5?
--
Elliotte Rusty Harold [EMAIL PROTECTED]
XML in a Nutshell 3rd Edition Just
James M Snell wrote:
Just an FYI,
http://wiki.apache.org/incubator/AriProposal
http://www.snellspace.com/wp/?p=323
http://www.snellspace.com/public/ari.tar.gz
We are proposing the creation of an Atom Reference Implementation
project at Apache and have donated source to kick things off.
On May 23, 2006, at 2:59 PM, Sylvain Hellegouarch wrote:
It seems to be good idea to do such promotion. However I wonder why
you
have not considerated using an existing project such as demokritos [1]
which is quite well advanced.
Demokritos might be quite well advanced but unfortunately
Demokritos might be quite well advanced but unfortunately Python code
is not very suited for us poor souls who still have to struggle with
java environments ;-)
I guess I kind of got that as well. That being said, it will be nice of
the project at some point can state exactly how it will
I could certainly do with more of a critical mass of users /
contributors / people-on-the-mailing-list
James
On 23/05/2006, at 8:59 AM, Sylvain Hellegouarch wrote:
It seems to be good idea to do such promotion. However I wonder why
you
have not considerated using an existing project
--On May 23, 2006 3:18:18 PM +0200 Ugo Cei [EMAIL PROTECTED] wrote:
Demokritos might be quite well advanced but unfortunately Python code is not
very suited for us poor souls who still have to struggle with java
environments ;-)
The goal is a reference implementation. The goal is to be
The goal is a reference implementation. The goal is to be exactly correct.
Being in a particular language, or even being fast enough to be usable,
is beside the point. In particular, a reference implementation should
always choose code readability over speed.
Fair enough.
If the goal is
I believe Jigsaw [1] is a an example of what you mean.
Jigsaw: http://www.w3.org/Jigsaw/
But you all knew that. ;)
- Sylvain
The goal is to have a reference implementation that is also usable.
However, I do have to be careful here, the IETF doesn't really do
reference implemenations so the naming of this project is a bit wrong.
We really shouldn't be calling it a reference implementation although
that is the kind of
In this particular case, it means providing an implementation that
allows, as closely as possible, everything that the spec allows. For
instance, if you look at the code, the Link element is marked as being
extensible and as allowing string content, both of which are explicitly
allowed by
I don't really want to get into a lot of detail here (it's not the
proper forum for it). The project will provide a Java-language Atom
parser, APP client, and some APP server side code with the goal of
providing as complete an implementation as possible.
And regarding the choice of the XML
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elliotte Harold wrote:
Of course, this requires the reference implementation to be developed
with the same authority that the spec writers have. That's not at all
the case here, so I suspect reference implementation is a false
statement. This
at
On May 23, 2006, at 4:53 PM, Walter Underwood wrote:
The goal is a reference implementation. The goal is to be exactly
correct.
Being in a particular language, or even being fast enough to be
usable,
is beside the point. In particular, a reference implementation should
always choose
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-23 17:20]:
As we have already seen on this list, RFC4287 lacks of
precision in some context, therefore I wonder what being
exactly correct represents.
Did I miss something? I remember several oversights of omission,
but none of imprecision.
FWIW, I removed the term reference implemenation from the proposal to
properly reflect the nature of the implementation.
Ugo Cei wrote:
at
On May 23, 2006, at 4:53 PM, Walter Underwood wrote:
The goal is a reference implementation. The goal is to be exactly
correct.
Being in a
Right. IETF specs cannot have an official reference implementation. The
best we can do, in this case, is to have a number of implementations
available that strive to a) implement the spec as completely as possible
and b) interoperate with one another as best as possible. The
reference
That sounds good to me.
Please not though that I didn't care about the language, my only
questions were:
1. Why not using an existing project?
2. How interoperable had you planned to be?
It seems these questions have more or less been answered so I'm fine :)
- Sylvain
Right. IETF specs
Sylvain Hellegouarch wrote:
Demokritos might be quite well advanced but unfortunately Python code
is not very suited for us poor souls who still have to struggle with
java environments ;-)
I guess I kind of got that as well. That being said, it will be nice of
the project at some point can
On May 17, 2006, at 12:46 PM, Byrne Reese wrote:
Speaking up:
http://www.majordojo.com/atom/
standardizing_the_atom_thread_extension.ph
p
No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.
Me too. Does something useful, does no harm, if it's broken in some
way
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of
+1. What Tim said.
- James
Tim Bray wrote:
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by
I've just sent off Draft -11 of Feed Thread that incorporates the
following updates per the feedback offered during the last-call discussions:
1. thr:when renamed to thr:updated. This is minor, I don't think it was
necessary, but some folks seemed to prefer thr:updated over thr:when.
2. New
I've had a hard time following this thread, but for what its worth I
buy Tim's reasoning.
+1
On May 23, 2006, at 12:26 PM, James M Snell wrote:
+1. What Tim said.
- James
Tim Bray wrote:
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable
At the end of the day, the marketplace will work within the
constraints of what 4287 allows; my feeling is that there are going to
be a ton of extensions that will attach unforeseen metadata at
arbitrary points with Atom documents, and implementations that fail to
store these and make
Greetings again. The Atompub WG will have our first (and maybe last!)
face-to-face meeting at the upcoming IETF meeting in Montreal at the
beginning of July.
The timing of us having our first WG meeting may seem odd, given the
fact that we completed the Atom format document long ago, and
At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote:
At the end of the day, the marketplace will work within the
constraints of what 4287 allows; my feeling is that there are going
to be a ton of extensions that will attach unforeseen metadata at
arbitrary points with Atom documents, and
Welcome to the messy world of standards. There might be a need for an
updated FTE RFC. On the other hand, if the market gives a big yawn,
there is probably no need to update the RFC if no one is using it. On
the third hand, it doesn't hurt to have it updated anyway; there are
lots of RFCs
On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)
I'm going to re-organize David's argument a little and deal with one
of his last points first.
Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.
I would say that furious debates
This sounds good so long as we can get the extensions BOF scheduled the
on the same day as the WG meeting. Also, it would be great if we could
get together for some face-to-face interop testing before and/or after
the WG meeting.
- James
Paul Hoffman wrote:
Greetings again. The Atompub WG
On 5/23/06, Tim Bray [EMAIL PROTECTED] wrote:
I would vociferously resist any such claim.
OTOH, there are more than a few products on the market right now that
back up just such a claim. So there's an existence proof, and most of
the APIs I've seen *do* make use simple vs. structured, but
At 2:31 PM -0700 5/23/06, James M Snell wrote:
This sounds good so long as we can get the extensions BOF scheduled the
on the same day as the WG meeting.
Good point. The fact that the WG meeting is one hour strongly
suggests that we will be on Tuesday afternoon, the traditional time
for
32 matches
Mail list logo
