Just to say that I strongly agree with Jan's points below. We should
work to use the link relation type properly, and not get dazzled by
the current misuse of the alternate relation.
I have been wondering if there would not be a case for different mime
types if one wanted to place a
this thread whether it's for today which I
assume
it is.
Terris
-Original Message-
From: Henry Story [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 9:42 PM
To: John Panzer
Cc: Lisa Dusseault; Atom Protocol; Atom
Subject: Re: In San Francisco/Bay Area
I'll be there at 6:30pm
better for me, but 7pm is okay too.)
-John
Lisa Dusseault wrote:
Thanks for setting this up Henry, I can be there Dec 6. 7pm is
much easier to make than 6pm if anybody's coming far, even just
from SF.
Lisa
On Dec 1, 2006, at 12:08 PM, Henry Story wrote:
Ok I suggest trying December 6th
Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.
What is dinner time in the bay? 6pm? 7pm?
Henry
On 28 Nov 2006, at 21:31, John Panzer wrote:
Any of those would be good for me. Be careful of the deep fried onion
rings at Tied House, though.
Henry Story wrote
There are all kinds of other things you don't know: like what's
inside the document, if the server is up, what the title is, ... What
interoperability problem is solved by having a new mime type? And
would that not be solvable by
atom:link rel=entry type=application/atom+xml href=a.xml /
On 24 Nov 2006, at 01:44, Henri Sivonen wrote:
On Nov 23, 2006, at 22:42, Henry Story wrote:
This is very nice, in that it opens up the possibility of placing
good RDF descriptions of these links at the http://www.iana.org/
assignments/relation/,
How could new link relations be described
It has been suggested that a good meeting location might be Tied
House in Mountain View [1]. It has a back room that's like a patio
but covered and heated for dinner on either
Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec
Any preferences?
Henry Story
[1] http
Very nice.
One thing I like about the current atom spec, is that the link
relations are in fact urls. The link relations are equivalent to the
urls generated by appending http://www.iana.org/assignments/
relation/ to the alternate, self, ... rel=... strings.
This is very nice, in that it
On 23 Nov 2006, at 14:28, Thomas Broyer wrote:
The feed keyword indicates that the referenced document is a
syndication feed.
Being a syndication feed is expressed by the media type, there's no
need for a 'rel' value.
The only reason for such a 'rel' is to replace the contents value in
I agree. It would be useful to work on placing a little bit more
weight on the rel relation rather than putting everything on the mime
type. After all if every link is going to be an alternate relation,
then what was the point of the rel=... attribute? We might as well
have stuck with
Hi,
I am in the San Francisco/Bay Area region for the coming month. Would
anyone in the area be up for a group meeting?
Henry
Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me
On 8 Nov 2006, at 19:49, Jan Algermissen wrote:
On Nov 8, 2006, at 5:57 PM, Henry Story wrote:
http://www.intertwingly.net/wiki/pie/PaceSparqlLink
Are you really suggesting to use POST for querying (as the Pace says)?
Sorry, it was my misreading of SPARQL protocol to think that POST
One very powerful solution would be to use a sparql link as
described in PaceSparqlLink [1]
This would point to a service end point such as the following:
http://roller.blogdns.net:2020/snorql/
to which a simple SPARQL POST or GET request can be made. The above
url points to the html view
On 2 Nov 2006, at 08:59, Thomas Broyer wrote:
[redirecting to atom-syntax]
This is also a protocol issue, because we are asking what to do with
the information in the atom feed. [1]
2006/11/1, Houghton,Andrew:
concept scheme URI: http://my.scheme.net/my-vocabulary/
concept URI:
On 2 Nov 2006, at 12:19, Thomas Broyer wrote:
[[
The term attribute is a string that identifies the category to
which the entry or feed belongs. Category elements MUST have a term
attribute.
]]
nowhere is there mentioned a IRI there,
IRIs are not forbidden either, and Andrew's description
Does xml:base and xml:lang apply to html encoded content?
There is the notion of language sensitivity and content is language
sensitive. So it makes sense to apply it to html content. But what
about the xml:base?
Henry
On 18 Oct 2006, at 01:40, James M Snell wrote:
[snip]
The spec says The value of atom:updated is only changed when the
change
to a member resource is considered significant. The use of passive
voice obscures who does what here. When the client doesn't suggest a
value for atom:updated,
Many thanks to Lisa for the lengthy and detailed comments. I am just
replying to those comments relating to the parts of the spec I
understand best.
On 18 Oct 2006, at 01:40, James M Snell wrote:
*Synchronization*
I predict that some AtomPub authoring clients will attempt to
On 18 Oct 2006, at 16:10, John Panzer wrote:
My assumption: Tim is correct. The server controls
atom:updated. While
the client is required to provide a valid atom:updated element, the
server can (and in most cases will) ignore that value.
Completely disagree.
If the server
not have any say in what the value of app:edited
is.
But special cases can be made. It's just that those would be
understood to be deviations from the norm.
- James
Henry Story meant to write:
[snip]
If the server controls atom:updated then what was the point of
the whole discussion
+1 to make the MUST a SHOULD
+1 on app:edited
But I think it would be really useful if we could have something that
allowed the user to specify how the feed should be sorted.
Henry
On 27 Sep 2006, at 22:14, Tim Bray wrote:
co-chair-mode
Please see the dialogue below.
/co-chair-mode
Thanks everyone for this really interesting discussion. I have added
a note to this effect to the latest atom-owl ontology [1].
In Atom-Owl we could easily do both.
[] :content xhtml:div xml:lang=frOui!/xhtml:div^:xhtml.
or we could have
[] :content Oui!@fr^:xhtml .
or
[] :content [
elements? Should those not perhaps be used instead on the
div element?
Henry
On 29 Jun 2006, at 00:11, Henry Story wrote:
Thanks everyone for this really interesting discussion. I have
added a note to this effect to the latest atom-owl ontology [1].
In Atom-Owl we could easily do both
The Atom-OWL group is working on an ontology for Atom. You can find
the latest version here
https://sommer.dev.java.net/atom/
It comes with a XSLT 2.0 and XQuery 1.0 transform from atom xml to
atom-owl. (The XQuery transform is the best). We were thinking of
adding relations from the
other
feedback to me or to the mailing list at http://groups.google.com/
group/atom-owl/
Sincerely,
Henry Story
[1] http://blogs.sun.com/roller/page/bblfish/20060614
Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
On 8 Jun 2006, at 14:44, Elliotte Harold wrote:
James M Snell wrote:
That's not quite accurate. Two entries with the same atom:id may
appear
within the same atom:feed only if they have different atom:updated
elements. The spec is silent on whether or not two entries
existing in
You can have two entries or feeds with the same id, as long as they
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all the same properties...
Henry
On 7
of agregators. If you have the same entry with the same id
but different content, which is it going to choose?
Henry
[1] http://groups.google.com/group/atom-owl/browse_frm/thread/
357e36c4ee9cd31b/
On 7 Jun 2006, at 20:40, James M Snell wrote:
Henry Story wrote:
You can have two entries
.
We are very open on what the best way to proceed is.
Yours sincerely,
Henry Story
Sem Web Researcher, Sun Microsystems
http://blogs.sun.com/bblfish/
[1] Session 7: Adventures in Formal Methods
http://www.w3.org/2006/03/01-TechPlenAgenda.html
[2
My first N3 representation of the example Service document, with 3
classes :Service, :Workspace, and :Collection
a :Service;
:workspace [ a :Workspace;
:title Main Site@en;
:primaryCollection [ a :Collection;
:title
I think they should all have the same id. But I don't have any good
arguments in favor. It just seems to make sense that way.
Henry
On 10 Mar 2006, at 18:44, James M Snell wrote:
If the feeds have the same atom:id, I would submit that they form a
single logical feed. Meaning that all of
Silly question probably, but is there a wiki mime type?
I was thinking of text/wiki or text/x-wiki or something.
I want people to be able to edit their blogs in wiki format in BlogEd
and be able to distinguish when they do that from when they enter
plain text, html or xhtml. Perhaps this is
On 1 Feb 2006, at 02:10, Eric Scheid wrote:
On 31/1/06 1:27 PM, James Holderness [EMAIL PROTECTED] wrote:
Actually I was thinking just a regular href and type. For example:
link type=application/atom+xml
href=http://mydomain.com/feed;
hreflang=fr
x:id=french_entry_id
and DELETEd)
Henry Story
PS. Not sure what I should do with the above. Perhaps write it up
somehow?
On 31 Jan 2006, at 02:17, James Holderness wrote:
Henry Story wrote:
Just re-reading your mail I think you make a good point that perhaps
translation is the wrong word to use. We would like
example above would be falsified a little
too easily.
Henry Story
http://bblfish.net/
This looks like a good place to look for a solution.
On 31 Jan 2006, at 03:27, James Holderness wrote:
Henry Story wrote:
Presumably one would need to add an x:feed=http://mydomain.com/
feed attribute for translations of entries that appear in other
feeds.
Actually I was thinking just
-owl.
Something like:
awol:id rdfs:subclassOf dc:identifier .
we would have to look at this case by case. Also should this be part
of the main ontology?
Henry Story
Sorry for being away for a while. I am back on this issue. We had
narrowed in on this quite well. It should be RFC time real soon.
On 24 Dec 2005, at 07:25, James Holderness wrote:
Henry Story wrote:
I think you have not quite grasped the point my graph was trying to
make. Perhaps I did
Sorry again to take so long to respond. I have been a little too busy
to respond recently.
On 4 Dec 2005, at 16:42, Simon Phipps wrote:
On Dec 4, 2005, at 14:33, Henry Story wrote:
I have written my first blog entry in French [1] which has made me
aware that
it would be very useful
them through a moderation stage. This
option was not available on google groups when I started the group.
So you non members can cc that group hapily now. :-)
Henry
On 22 Dec 2005, at 18:44, Simon Phipps wrote:
On Dec 22, 2005, at 15:34, James Holderness wrote:
Henry Story wrote:
Does
on the beach ;-)
On 22 Dec 2005, at 16:34, James Holderness wrote:
Henry Story wrote:
Does Atom allow there to be multiple parallel renditions of a
blog entry in different languages?
So it is not really possible to put atom entries with the same id
and updated time stamp in a feed
I still think it would be good to be able to have to entries in one
feed and be able to state that they are translations of one another.
I don't think that putting them in different feeds is going to cover
all the cases. See below.
On 22 Dec 2005, at 17:45, James M Snell wrote:
One
Yes. That is one solution. But what we are looking for is how one can
state that two entries in the same feed are translations of one another.
Henry
On 22 Dec 2005, at 20:52, James M Snell wrote:
Hmmm.. interesting thought, hadn't considered that.
rel=self should always point to *this*
On 1 Dec 2005, at 17:50, Uche Ogbuji wrote:
On Tue, 2005-11-29 at 10:25 +0100, Henry Story wrote:
On 29 Nov 2005, at 00:31, Luke Arno wrote:
On 11/28/05, Ernest Prabhakar [EMAIL PROTECTED] wrote:
Hi Henry,
On Nov 23, 2005, at 3:22 AM, Henry Story wrote:
A few improvements of atom over
practical context.
If the only practical effect this discussion may have is help people
think about feeds a little differently, something will have been
achieved.
Thanks again for participating,
Henry Story
http://bblfish.net/blog/
[1] http://en.wikipedia.org/wiki
On 29 Nov 2005, at 00:31, Luke Arno wrote:
On 11/28/05, Ernest Prabhakar [EMAIL PROTECTED] wrote:
Hi Henry,
On Nov 23, 2005, at 3:22 AM, Henry Story wrote:
A few improvements of atom over directories is that our feed can
contain not just the current version of an entry, but all previous
I think I remember was a feature supported by
the vms file system.
Of course the URI id construct and the fact that the web does not
have partitions, allows one to keep track of the identity of a file
over the whole web, which simple inodes just cannot do.
Henry Story
[1] http
about the state of a resource with
given :id at an :updated time.@en;
rdfs:subClassOf [ owl:complementOf :Id ].
Since :Entry and :Feed are subclasses of :Version, that means that
Entries or feeds cannot be ids. Perhaps that is too harsh.
Henry Story
On 12 Nov 2005, at 12:48, Henry
On 12 Nov 2005, at 10:26, Danny Ayers wrote:
[snipped a very good conversation]
(I've cc'ed the atom-owl list, this is certainly in scope over there).
I think Bill's right about the direction being the issue, and has
probably got the right answer with adding another property to the
entryURI,
Well it clearly should be able to be generated someplace other than
the server.
That was one major point of having ids: to be able to allow entries
to be moved
from one server to another whilst allowing them to keep the same id.
In order
for that to work the server needs to accept the id
it meshes with the intent of these
intersecting efforts (OWL, microformats, CSS, etc.). This idea fits
very well with how I want to use Atom and microformats but it could
introduce grief to others who want to play in my sandbox.
Scott
On 10/28/05, Henry Story [EMAIL PROTECTED] wrote:
On 28 Oct
On 24 Oct 2005, at 22:59, A. Pagaltzis wrote:
* Antone Roundy [EMAIL PROTECTED] [2005-10-24 22:35]:
Interesting. Filling an attribute with a list of URIs doesn't
really appeal to me though.
+100 (me and all my co-voting cats)
How about this:
link rel=enclosure type=audio/mpeg
I'd like to propose an extension that would allow something very much
like
icon and logo to be added to an entry, the way it currently is
allowed on a feed.
I have been publishing entries like this for over a year now [1], and
so has
James Gosling [2], and other users of BlogEd. It would
updated2003-12-13T18:30:02Z/updated
summarySome text./summary
/entry
Makes sense to me.
Henry
http://blogs.sun.com/roller/page/bblfish/
On 25 Oct 2005, at 22:23, Henry Story wrote:
On 25 Oct 2005, at 22:08, James M Snell wrote:
I've been wanting to do the same thing for link
I agree self would do well. But it is true that it's current
definition
is a little vague. I don't suppose one can refine it in a way
consistent with its current definition?
In any case this all looks good to me. As soon as we agree on the
names, I will
implement these links in BlogEd,
+1 to all too.
On Fri, 21 Oct 2005, Eric Scheid wrote:
Date: Fri, 21 Oct 2005 10:47:57 +1000
From: Eric Scheid [EMAIL PROTECTED]
To: Atom Syntax atom-syntax@imc.org
Subject: Re: New Link Relations -- Ready to go?
+1 to all
My laptop broke down so I am having touble following all of this thread,
but I agree that next, prev, ... should just suggest a linked list.
There should then be special links for hist-prev, hist-next, ... that
are in rdf terms sub-properties of prev, next, etc... On the atom-owl
mailing
I am ok with next, prev, ... but I suppose I do have a question that is
similar to Marks: how do I know in what order the results are listed? Are
they in historical order? Are these feeds grouping entries in alphabetical
order, in inverse historical order? Perhaps in alphabetical order of
I am ok with next, prev, ... but I suppose I do have a question
that is similar to Marks: how do I know in what order the results
are listed? Are they in historical order? Are these feeds grouping entries
in alphabetical order, in inverse historical order? Perhaps in
alphabetical order of
This looks good.
Is the 'first' the feed document that changes, whereas 'next' and 'last'
point to the archives? (in a feed history context?)
Henry
On Fri, 14 Oct 2005, James M Snell wrote:
The way I look at this is in terms of a single linked list of feeds. The
ordering of the entries
, Henry Story wrote:
I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved
over to
the protocol side of things. Probably just because the debate was
taking up
too much time...
So yes. 'prev' and 'next' have always
the possibility of multiple language versions of the same
update of
an entry.
Henry Story
The following two entries are in a feed
entry xmlns=http://www.w3.org/2005/Atom; xml:lang=de
titleAsylgesetzrevision - Aus humanitärer Sicht inakzeptabel!
/title
link rel=self type=text/html hreflang=de
.
Proposals
can also decide to use their own name space like the current feed
history
namespace.
Henry Story
On 3 Oct 2005, at 07:15, Mark Nottingham wrote:
My .02, FWIW, and off the top of my head;
I think this is a well-intentioned effort, but at the wrong end of
the process. The market (i.e
I think this is good, but I would prefer the atom:link to be used
instead of
the fh:prev structure, as that would better fit the atom way of doing
things.
I also think it may be very helpful if we could agree on an extension
name space
that all accepted extensions would use, in order to
into the content
or the metadata. Where should the metadata go?
Henry Story
[1] http://www.codezoo.com/about/doap_over_atom.csp
[2] http://blogs.sun.com/roller/page/bblfish/20050910
On 10 Sep 2005, at 01:51, James M Snell wrote:
Bob Wyman wrote:
I’ve written a blog post pointing to a wonderful demo
?
entry=java_annotations_the_semantic_web
In short: RDF can be mapped directly onto Java Beans. Just as Beans
can be plugged
together, so RDF markup can be plugged together. Welcome to the world
of OO xml.
Henry Story
On 30 Aug 2005, at 07:49, Bob Wyman wrote:
I’m sorry, but I can’t go
Mhh. Good point too.
For some reason though, this is starting to make me think that a feed
is an entry again...
Henry
On 30 Aug 2005, at 13:23, Graham wrote:
How would this apply to the most problematic example of a list
feed, the BBC news headline page:
feed so that
the rest of us can read it. If you update the list, then just
replace the entry in your feed. If you create a new list (Top 34?)
then insert that in the feed along with the “Top10” list.
Henry Story also proposed atom:id to be order-related:
feed xmlns=http://www.w3.org/2005
On 25 Aug 2005, at 15:45, Joe Gregorio wrote:
On 8/25/05, James M Snell [EMAIL PROTECTED] wrote:
Up to this point, the vast majority of use cases for Atom feeds is
the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated
On 25 Aug 2005, at 17:06, A. Pagaltzis wrote:
* Henry Story [EMAIL PROTECTED] [2005-08-25 16:55]:
Do we put base64 encoded stuff in html? No: that is why there
are things like
img src=...
img src=data:image/gif;base64,R0lGODlhAQABAIAAAP///
yH5BAEKAAEALAABAAEAAAICTAEAOw
Mhh. I have not looked into this. But is not every desktop aggregator
a robot?
Henry
On 25 Aug 2005, at 22:18, James M Snell wrote:
At the very least, aggregators should respect robots.txt. Doing so
would allow publishers to restrict who is allowed to pull their feed.
- James
), but it
does work OK for general web content.
wunder
--On August 25, 2005 10:25:08 PM +0200 Henry Story
[EMAIL PROTECTED] wrote:
Mhh. I have not looked into this. But is not every desktop
aggregator a robot?
Henry
On 25 Aug 2005, at 22:18, James M Snell wrote:
At the very least
On 22 Aug 2005, at 18:29, James M Snell wrote:
Bill de hÓra wrote:
As we have no processing model for this, my answer to Paul's
question is
that feed level extensions do not inherit/cascade/scope over entry
level
ones, irrespective of whether they're foreign or not, and that the
best
only read that spec
quickly [1] but this would
mean that the following
fh:history xlink:href=./archives.archive1.atom
would widely be understood to work with the xml:base.
Henry Story
[1] http://www.w3.org/TR/2001/REC-xlink-20010627/
This interpretation of extensions seems very fragile
|---entry _
|id- tag:myblog,2005/e2
|---title--- another entry
I think we require some form of inferencing beyond what is available
in OWL
to achieve this result. This could probably be achieved through some
simple
N3 rules.
Henry Story
, and it caused
me no end of trouble: all those problems vanished as soon as they
allowed relative references.
So if relative references are allowed in links perhaps the following
would be better:
link type=http://purl.org/syndication/history/1.0/next; href=./
archives/archive1.atom
Henry Story
[1
consumers of your
extension, and even if your
extension becomes world famous, it certainly won't be true for all
the other extensions that people will come up with. So I think we
should be setting a good example in these first extensions we write.
Henry Story
Cheers,
On 16/08/2005, at 11
On 16 Aug 2005, at 21:50, Robert Sayre wrote:
On 8/16/05, Henry Story [EMAIL PROTECTED] wrote:
On 16 Aug 2005, at 21:00, Mark Nottingham wrote:
I very much disagree; relative references should be allowable in
simple extensions, and in fact the rationale that Tim gives is the
reasoning I
of by the http
expiry dates and
cache control mechanism. Of course if this is so, I think it should
be noted
clearly in the history spec. ((btw. Is it easy to set expiry dates
for documents served
by apache?))
Henry Story
On 10 Aug 2005, at 04:46, James M Snell wrote:
This is fairly quick
Sorry to note the obvious, but does this not sound so much like a
good reason we should
have engineered atom to *be* RDF? Is this not exactly one of the many
problems that RDF
sets out to solve?
Henry Story
On 10 Aug 2005, at 02:34, Tim Bray wrote:
On Aug 9, 2005, at 5:11 PM, David
...
On 29 Jul 2005, at 17:01, Eric Scheid wrote:
On 29/7/05 11:39 PM, Henry Story [EMAIL PROTECTED] wrote:
Below I think I have worked out how one can in fact have a top20
feed, and I
show how this can be combined without trouble with the
history:next ...
link...
On 29 Jul 2005, at 13:12, Eric
cought up with the changes since they last looked at the feed.
Perhaps something like this:
history:prev archive=yeshttp://liftoff.msfc.nasa.gov/2003/04/
feed.rss/history
Henry Story
On 9 Aug 2005, at 18:32, Walter Underwood wrote:
--On August 9, 2005 9:28:52 AM -0700 James M Snell
[EMAIL PROTECTED] wrote:
I made some proposals for cache control info (expires and max-age).
That might work for this.
I missed these proposals. I've been giving some thought to an
this
could be explained in the Feed History RFC. Or are there other
reasons to
add and expires tag to the document itself?
Henry Story
On 9 Aug 2005, at 19:09, James M Snell wrote:
rules as atom:author elements.
Here it is: http://www.intertwingly.net/wiki/pie/PaceCaching
The expires and max
. And this case also seems to
be worked upon in the API
I think.
more below...
On 23 Jul 2005, at 18:14, Mark Nottingham wrote:
On 19/07/2005, at 2:04 AM, Henry Story wrote:
Clearly the archive feed will work best if archive documents, once
completed (containing a
given number of entries
Below I think I have worked out how one can in fact have a top20
feed, and
I show how this can be combined without trouble with the
history:next ...
link...
On 29 Jul 2005, at 13:12, Eric Scheid wrote:
On 29/7/05 7:57 PM, Henry Story [EMAIL PROTECTED] wrote:
1- The top 20 list: here
The following page has been badly spammed
http://www.intertwingly.net/wiki/pie/AtomOWL
and it looks like the fact that it was changed never appeared in the
RSS feed.
Henry
I have just published a feed for my blog at http://bblfish.net/blog/
blog.atom
I use logo and icon tags. Am I using it correctly?
I wanted to add logos and icons to each of the entries too, as each
entry at
http://bblfish.net/blog/ has an associated image and logo. I guess I
will
have to
would not do
more lookups than they are doing now...
I think this would be the correct strategy.
Henry Story
that the feed had responsibility for. As this could be
quite large
some form of navigation may be necessary. Perhaps this is the type of
thing
that the protocol group is working on.
Henry Story
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
forward to having this functionality.
Thanks a lot for the
huge effort you have put into presenting this idea so clearly and
with such patience.
Henry Story
On 18 Jul 2005, at 09:59, Stefan Eissing wrote:
Am 16.07.2005 um 17:57 schrieb Mark Nottingham:
The Feed History draft has been updated
It would be easy to add atom to BlogEd, though I really would like the
link rel=ext;next href=http://bblfish.net/blog/archive.
10.atom
to be agreed upon. This would allow me to place all the blog content
in an
archive. It would of course also be useful to have the namespace.
Henry
, at 12:36, Henry Story wrote:
Hi, I am looking for a tool to make it pleasant to resolve merge
conflicts between a branch and the
HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone
know a good tool that one could
use for this?
Henry Story
Sorry, wrong list. :-/
Henry
On 23 Jun 2005, at 18:22, Henry Story wrote:
A couple of people pointed me to Eclipse for this, and it does
indeed work well for this (thoug
the quality of the diffs is not so good as IntelliJs). If it were
not so complicated to transform
a checked out CVS
about extending atom? This was meant to be a
feature of it,
and especially of the link concept.
Henry Story
[1] https://bloged.dev.java.net/
[2] http://bblfish.net/blog/
On 18 Jun 2005, at 06:27, James M Snell wrote:
Sam asked
P.S. Why is this on atom-sytax? Is there a concrete proposal we
The best solution is just to add a link types to the atom syntax: a
link to the previous feed document that points to the next bunch of
entries. IE. do what web sites do. If you can't find your answer on
the first page, go look at the next page.
How do you know when to stop? If the
I completely agree. At the core, a feed is just a list of state
changes to web resources.
It will be the perfect format for notifying search engines of all
the changes to a web
site, thereby massively reducing the time it will take them to crawl
the web.
Henry Story
On 3 Jun 2005
I was wondering if I had understood this correctly: a feed can have
entries in a number of categories. Each of these categories may
themselves have feeds. These category feeds will all have the same id
as the main feed, though they may have different titles and subtitles
to reflect the
On 6 Jun 2005, at 16:30, Tim Bray wrote:
On Jun 6, 2005, at 6:12 AM, Henry Story wrote:
I was wondering if I had understood this correctly: a feed can
have entries in a number of categories. Each of these categories
may themselves have feeds. These category feeds will all have the
same
is not unlikely to do a lot of safety checks to find
out where the gun is. He may for
example scan the person who told him he has not gun anyway, just to
make sure.
On 25 May 2005, at 22:57, Antone Roundy wrote:
On Wednesday, May 25, 2005, at 02:26 PM, Henry Story wrote:
Since the referents
1 - 100 of 200 matches
Mail list logo
