are fundamental, so they cannot be
swept under the
carpet. They will keep popping up.
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg15608.html
[2] http://www.w3.org/DesignIssues/Notation3.html
My thought currently is that atom:updated by being the sole date in
atom is in
fact what people are thinking of as atom:modified.
It is just specified very flexibly and constrained not by language
but by how it will
be used. The game of publishing entries will push people to be
Simplify, simplify. I am for removing all inheritance mechanisms...
Henry
On 24 May 2005, at 02:02, Bill de hÓra wrote:
Eric Scheid wrote:
oh darn. This damn inheritance stuff is nasty.
Inheritance suggests a programming model to allow the evaluator to
be coded for it. It's rarely as
On 23 May 2005, at 07:22, A. Pagaltzis wrote:
In [EMAIL PROTECTED]
(http://www.imc.org/atom-syntax/mail-archive/msg15517.html),
Antone Roundy suggests:
make atom:author plural
keep atom:contributor
punt bylines to an extension
+1 to all
I think that makes sense, especially if one thinks
*directly*
contain an entry with the same atom:updated value. It would allow
that a feed could contain two
feeds each with different entries containing the same id and the same
atom:updated time stamp.
It would then be up to the consumer to decide which one it trusts.
Henry Story
May 2005, at 02:51, Robert Sayre wrote:
On 5/21/05, Henry Story [EMAIL PROTECTED] wrote:
On 22 May 2005, at 02:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally
On 18 May 2005, at 17:30, Antone Roundy wrote:
On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote:
I supposed the surest way to make it impossible to fake the id, is
to specify that
by dereferencing the id and doing a GET (whatever the correct
method of doing
On 21 May 2005, at 08:44, Eric Scheid wrote:
On 21/5/05 4:24 PM, Henry Story [EMAIL PROTECTED] wrote:
So those are just a few thoughts on the topic. It just seems that
if one
works with the web these phishing problems seem to disappear.
all good stuff, with the exception of making atom:id
On 22 May 2005, at 01:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
So, it's about disambiguating versions of an entry, right?
No. It has nothing to do with versions or even
variants. I have
explained that on numerous occasions. The
On 22 May 2005, at 02:27, Robert Sayre wrote:
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
Temporal order of what? They are all the same entry, so what is it
you are temporally ordering?
We are discussing the temporal ordering of multiple non-
identical
the two in the aggregation,
which really aren't, are required to be treated as the same.
I always thought that two entries with the same id should be treated
as the same entry.
What makes you thing otherwise?
Henry Story
http://bblfish.net/blog/
Should one not then to make atom:update a MAY?
We don't really need 2 MUST dates.
Henry
On 16 May 2005, at 00:12, David Powell wrote:
PaceAllowDuplicateIDs received some opposition because of its use of
atom:updated to differentiate multiple revisions of an entry [1][2]
[3].
I've posted a couple
On 12 May 2005, at 23:22, Eric Scheid wrote:
On 13/5/05 7:12 AM, Henry Story [EMAIL PROTECTED] wrote:
Just to recapitulate: we have 2 feed documents with successive
atom updated
values, and with the same entry (same id) with the same time
stamp but some
values that are not identical. Does
the mistake artificially in your own feed by
increasing the time precision. So if the original entries both claim to
have been updated at 12:45 you could have one of them be modified at
12:45:30
and the other at 12:45:31.
Just a thought.
Henry Story
On 12 May 2005, at 01:40, David Powell wrote:
I'm
On 12 May 2005, at 18:49, Eric Scheid wrote:
On 13/5/05 2:04 AM, Roger B. [EMAIL PROTECTED] wrote:
Gah! What is the true atom:updated for the following entry?
Eric: The entry-level version, IMO.
What if an atom processor had previously seen that entry with that
atom:updated ... should it do
On 10 May 2005, at 04:23, Antone Roundy wrote:
On Monday, May 9, 2005, at 07:52 PM, Eric Scheid wrote:
rel=self is in no way a substitute for an identifier
Why not?
the uri can change.
Yes, I acknowledged that a little after why not?. So we have a
tradeoff--greater permanence vs. greater
If I can summarize your point:
You prefer applications that only allow one entry with the same
id per feed.
Those that don't should use a different format that has not been
defined yet.
This seems little weak an argument to me. I think we should permit
certain types
of communication to
On 8 May 2005, at 16:35, Graham wrote:
On 7 May 2005, at 1:35 pm, Henry Story wrote:
My definition is making me wonder whether I should not in fact
accept that
link alternate is a MUST.
Not really. There's no reason why the resource an Atom entry
describes has to be visible online anywhere
On 8 May 2005, at 21:43, Reto Bachmann-Gmuer wrote:
back home and looking at the code: could you give me a hint on how to
get the instances of AtomContent given a
com.sun.labs.tools.blog.Blog or
org.openrdf.model.Graph (I was looking at the SesameRDFFactory).
Well you can get all instances of a
Some have been clamoring for a good definition of an entry.
Here is one I have thought of recently.
An Atom Entry is a resource (identified by atom:id) whose
representations
(atom:entry) describe the state of a web resource at a time
(the link alternate)
Any thoughts?
Henry
Tonight something incredible happened to me. You won't believe it. I
was walking
back from the pubs when I got snapped by a passing space ships full
of hyper advanced aliens. They did various experiments on me, and
cloned me 1000
times. It is terrible. I just don't know what to do.
I suppose
://google.com you get todays front page. Tomorrow you get
tomorrows front page.
What's the problem? Is http://google.com a hidden category system?
Henry Story
http://bblfish.net/blog/
I have put PaceAlternateLinkWeakening on the wiki, though it was
discusses on this
list, as it might not have cought the eye of the editors/secretary.
http://www.intertwingly.net/wiki/pie/PaceAlternateLinkWeakening
I think this is very uncontroversial clarification.
Henry Story
On 5 May 2005, at 16:38, Graham wrote:
On 5 May 2005, at 3:32 pm, Henry Story wrote:
As I explained in my lengthy reply to your lengthy post, I think
one should be able to do either.
Each way has its advantages and disadvantages. Let the publisher
decide which mechanism to use.
Well please
Hi Dave,
nice to see you participate here. I understand your points, and
I myself thought the
way you did for a while.
[Oops, I see now that you have retracted your point. Oh well. I had
already started writing
the following]
On 5 May 2005, at 17:27, David M Johnson wrote:
I'm -1 on
On 5 May 2005, at 17:53, Graham wrote:
On 5 May 2005, at 4:22 pm, Henry Story wrote:
If you don't want to keep a history of the entries all you need to
do is drop all but the
latest entry with the same id. There is nothing more to it. Just
show the user the last
one you came across
*of* the id resource, but these
representations
are *about* the state of some other resources at a particular time
(most notably the
link alternate resource).
Henry Story
http://bblfish.net/blog/
e.
I'll +1 on MAY.
On 27 Apr 2005, at 04:29, Robert Sayre wrote:
On 4/26/05, Tim Bray [EMAIL PROTECTED] wrote:
Paul I are gonna watch a little more debate and then
we'll call rough consensus one way or the other, at which point I at
least will become crushingly rude to anyone who wants to invest
the scenes.
As far as I can remember not one good reason was put forward as to why
there should
be a restriction of one entry with the same id per feed. In fact I was
nearly convinced
that the consensus was to drop the restriction.
So I call for a real open vote on the issue.
Henry Story
On 19 Apr
On 19 Apr 2005, at 18:27, Bill de hÓra wrote:
Henry Story wrote:
So I call for a real open vote on the issue.
You don't need to call for a vote, just ask the chairs/editors who
keep track of such matters, about the particular specification.
Well we need some objective way to tell what
of anything, so I'd better not participate anymore.
On 19 Apr 2005, at 19:20, Paul Hoffman wrote:
At 6:12 PM +0200 4/19/05, Henry Story wrote:
I don't see where the consensus was by the way.
Correct. There was no consensus to remove the current wording.
And I never saw any vote on the
issue
Just to end on a positive note, I'll +1 this suggestion by Graham.
Henry
On 19 Apr 2005, at 18:30, Graham wrote:
I'm in favour of allowing duplicate ids when the source-id is
different to simplify creating merged feeds, which would allow the
client to figure out what to do. Under any other
My mother does this all the time. :-)
On 8 Apr 2005, at 14:23, Bill de hÓra wrote:
:)
Only that it's common enough (in my part of the world anyway) to send
short messages in subject lines that end with 'eom'. The point is that
people do communicate solely through subject lines in email. I think
Here is a nice small surgical change.
I am not sure if I have convinced Thomas Broyer with the diagrams I put
online,
but I am still very happy with the following replacement, after having
carefully
looked at the criticisms.
Proposal A
--
replace
[[
The value alternate signifies that
Are the next and previous links that we thought may be attachable
to the feed
really too controversial to get into the final atom spec? They would be
really useful
to archive feeds.
Henry Story
be alternate versions of a resource?
Perhaps you mean that they are alternate versions of the
representations described by the
urn:uuid:1225...?
[1] http://www.imc.org/atom-syntax/mail-archive/msg13940.html
[2] see: http://www.imc.org/atom-syntax/mail-archive/msg13959.html
Henry Story wrote:
On 1 Apr
On 3 Apr 2005, at 23:02, Thomas Broyer wrote:
Henry Story wrote:
Perhaps you mean that they are alternate versions of the
representations described by the urn:uuid:1225...?
That's it! (I think...)
Now that we agree, I let you use the web-arch to describe it.
Ok. So let us try the slightly clumsy
On 1 Apr 2005, at 19:52, Thomas Broyer wrote:
Henry Story wrote:
On 1 Apr 2005, at 14:53, Eric Scheid wrote:
Prior art in other specs says the relationship is from where the
link is
found, and to the thing at @href.
I think we are agreeing here.
The link is from the representation entry/entry
On 2 Apr 2005, at 14:16, Eric Scheid wrote:
On 2/4/05 8:15 PM, Henry Story [EMAIL PROTECTED] wrote:
no. ...omething.else.atom is a resource, not a representation [1].
So what
you mean to say is that ...somethingelse.atom is an alternate
resource of
me.
Firstly, why is html.../html
On 1 Apr 2005, at 01:38, Eric Scheid wrote:
On 1/4/05 9:10 AM, Henry Story [EMAIL PROTECTED] wrote:
The value alternate signifies that the containing element is an
alternative
representation of the resource identified by the IRI in the value of
the href
attribute.
You do realise you've
, Henry Story wrote:
I would just like to revisit this question, because it will help
clarify
the alternate relation.
On 1 Mar 2005, at 11:39, Henry Story wrote:
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
My thinking goes like this,
- Is there a difference between an entry
On 1 Apr 2005, at 00:34, Mark Nottingham wrote:
On Mar 31, 2005, at 10:07 AM, Henry Story wrote:
The value alternate signifies that the containing element is an
alternative
representation of the IRI in the value of the href attribute.
...an alternate representation of the resource identified
I would just like to revisit this question, because it will help clarify
the alternate relation.
On 1 Mar 2005, at 11:39, Henry Story wrote:
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
My thinking goes like this,
- Is there a difference between an entry and the chunk of XML you
clearer to some :-)
Henry Story
[1] http://www.atompub.org/2005/03/12/draft-ietf-atompub-format-06.html
[2] the title attribute of the link is called l_title to avoid
confusing it with the
title element of the entry
[3] I am surprised the web arch ontology does not have the vocabulary
for
:type
+1
I think it makes a lot less sense for a feed than it does for an entry.
Henry
On 23 Mar 2005, at 14:19, Brett Lindsley wrote:
I know this discussion has occured before, but I would like to revisit
the question of why an atom:feed MUST contain at least one atom:link
element with a relation of
Thanks, that helps a lot. Perhaps what is missing are use cases.
Henry
On 29 Mar 2005, at 03:34, John Panzer wrote:
Henry Story wrote on 3/28/2005, 4:12 PM:
- I must have missed the arguments about self. But the documentation
does not really
help me understand what I would want to use that link
thoughts on that?
Henry Story
[1] http://bblfish.net/blog/page5.html#43
[2] http://www.lessig.org/blog/archives/002790.shtml
:
- you have to drop (c)
- or you have to give the relation a name other than atom:id
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg13618.html
[2] http://plato.stanford.edu/entries/mereology/
[3] http://xmlns.com/foaf/0.1/
On 18 Mar 2005, at 16:23, Thomas Broyer wrote:
I propose adding
What's the problem exactly? The spec looks quite nice to me on the
whole.
((Perfection would come with an OWL semantics as shown by RSS1.1, but
otherwise it looks
ok.))
Henry Story
On 16 Mar 2005, at 16:17, Graham wrote:
On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote:
PaceHeadless. The chairs
.
In any case I have seen no proof that having a feed document with
multiple entries
with the same id may have any problematic consequences. On the other
hand it would
be overwhelmingly helpful.
Henry Story
cheers
Bill
[1] I emphasise 'sensibly say' here rather than 'sensibly do'. Just
because
On 23 Feb 2005, at 08:53, Henry Story wrote:
On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
Sorry that should have been Paul Hoffman wrote:
My read of the mailing list is that people are simply looking at the
model described in the document differently. Some folks actively
want the model the way
, but I would rather wait to
see where the whole new version of the spec has put us before embarking
on
the debate.
I gather it should be ready any time now.
Henry Story
On 23 Feb 2005, at 12:10, Bill de hÓra wrote:
Henry Story wrote:
Bill de hÓra then responded:
[[
-1. That is of no little value
On 20 Feb 2005, at 17:10, Graham wrote:
On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same
atom:id.
Which part of universally unique didn't you understand?
Ok, I see so you interpret the universally unique in
[[
An Identity construct
notice, have absolutely no argument to
defend your case.
Henry Story
On 18 Feb 2005, at 23:55, Graham wrote:
Allowing more than one version of the same entry in a syndication feed
is unacceptable in itself, which is fundamentally incompatible with
archive feeds, no matter what the conceptual
On 18 Feb 2005, at 23:55, Graham wrote:
Allowing more than one version of the same entry in a syndication
feed is unacceptable in itself, which is fundamentally incompatible
with archive feeds, no matter what the conceptual definition of id
is.
Graham
Let me make my point even clearer. If
On 19 Feb 2005, at 16:46, Graham wrote:
On 19 Feb 2005, at 11:23 am, Henry Story wrote:
Let me make my point even clearer. If something is fundamentally
incompatible,
then it should be *dead-easy* to prove or reveal this incompatibility.
i) Syndication documents shouldn't ever contain multiple
that PaceRepeatIdInDocument tried to disambiguate
one
way and others tried to disambiguate the other way.
As such it correctly resolves an ambiguity by allowing both options.
Henry Story
Ps. text above written quickly cause I have to go do some exercise.
types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate
one
way and other Paces tried to disambiguate the other way.
As such it correctly resolves an ambiguity by allowing both options.
Henry Story
Ps. text above written quickly cause I have to go do some
Story
On 15 Feb 2005, at 20:38, Henry Story wrote:
On 15 Feb 2005, at 20:12, Tim Bray wrote:
PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it. But now we have a problem, in
that this removed ambiguity in one direction, just closing it leaves
- the counter proposal is making life more difficult for deployers
of atom who instead of just being able to paste their new entry into
a feed document must now verify that that document not have another
entity with the same id.
Henry Story
On 11 Feb 2005, at 22:40, Norman Walsh wrote:
The options as I see them:
1. I could lie.
According to some people in this group there is no way you can lie,
since there is no semantics to atom, it is just pure syntax!
For something to be a lie it has to misrepresent the truth, and for
that to
to
the other on this issue), I think we should rather try to decide
on by weighing as Bob Wyman did, the advantages of each.
And if this still does not allow one to choose one should perhaps
just allow both.
Henry Story
Ps. If you do read this please send me a postcard, or short e-mail
:-)
Cheers
proceeding any further it may be worth now comparing the
complexity of both proposals in detail. My guess is that the historical
one is just a little surprising, but that is all.
Henry Story
in your feed. The spec allows you to remove
all the old versions if you wish. After all the Present time, is just
one element in the sequence of history.
People who only want to live in the present don't negate history. They
just don't remember it.
Henry Story
On 19 Jan 2005, at 10:38, Henry Story wrote:
I think the easiest way to get what you want is a 2 step procedure:
1. Merge the Head with the Entry constructs. They are not different
enough
for the difference to be important.
2. Make a Feed a subclass of Entry, with the extra property
-1 I agree. Recursion can be placed in the model. It does not
need to be in the syntax. In any case this is too big a change
too late in the game.
Henry
On 7 Feb 2005, at 21:08, Antone Roundy wrote:
-1: recursion is too complex and bulky.
On 5 Feb 2005, at 00:34, Robert Sayre wrote:
Antone Roundy wrote:
3.5 Identity Constructs
An Identity construct is an element whose content conveys a
permanent, universally unique identifier for the resource
(instantiated|described) by the construct's parent element. An Atom
Document MAY
chronlogically
by the modified date when they are. This may be a protocol issue, or it
may just
be a matter of adding a special info to the feed to specify its
ordering.
Henry Story
http://bblfish.net/
On 4 Feb 2005, at 20:27, Walter Underwood wrote:
--On February 3, 2005 11:21:50 PM -0500 Bob Wyman
be completely up to the user. Some users may want only to see
entries that they have read
that have changed, as this may show a change of position of interest to
them.
Henry Story
--
Dave
time I am fully behind every movement to remove non core
elements from Atom. Lets have a clean spec well defined spec.
When enough people are left outside of the core, then I am sure talk
of extensions will finally get to be serious.
Henry Story
On 4 Feb 2005, at 09:29, Bob Wyman wrote:
We decided
Have you had any more luck with this part of the mapping? Is this a
problem with the current Atom syntax if not?
Henry Story
On 28 Jan 2005, at 22:27, David Powell wrote:
I think it
handles everything except for xml:lang - I'm not sure what's happening
with xml:lang at the moment - but it should
On 5 Feb 2005, at 13:49, Henry Story wrote:
So perhaps what we could do in the next weeks is fill in the work
I started in my proposal AtomAsRDF, that would allow Atom to be
seen as an RDF/XML document, though one constrained by an Relax-NG
syntax.
This will require a week or two of serious group
very nicely and inconspicuously.
At one point I had thought that properties such as author should
be directly attached to the id construct, since they are immutable.
But then one gets into problems of which are essential and which non
essential properties...
Henry Story
--
Dave
On 5 Feb 2005, at 18:48, Mark Nottingham wrote:
On Feb 5, 2005, at 4:38 AM, Henry Story wrote:
You put this in terms of databases and I put the question in terms of
graphs (which if you
have an rdf database to store your triples comes to the same thing).
And my feeling is here that we should
don't understand what the fuss about the head
element in the feed is (which is not quite to say that I am fully behind
the head_in_entry). I think the head element is just a special entry.
Henry Story
the user of the search engine made.
Of course if an entry has a tag such as origin (which used to be on
the
table) then the entry it points to would be part of the metadata of the
entry and so be a legitimate way of creating special selection of
entries.
Henry Story
A really clear way to specify this is to say that an id is a functional
relation between
an entry and a identity construct.
This implies:
-An Entry can only have one id.
-Different Entries can have the same id.
Of course because there is a bit of a confusion as to what is meant by
an Entry
on the icon
brings you to a
the original image the icon is a representation of. In one case [1] it
occurred to me
that have been more intuitive to have clicking on the image bring up a
video.
Henry Story
[1] http://www.bblfish.net/blog/page3.html#25
On 2 Feb 2005, at 07:49, Tim Bray wrote:
Having
pace,
that a Feed is a structure that is a subclass of the Entry structure.
And then we will really cut the
length of the spec down to its core.
Henry Story
On 2 Feb 2005, at 17:17, Julian Reschke wrote:
Graham wrote:
Any chance of renaming atom:tagline to atom:subtitle? The two sample
feeds posted
and an
OWL ontology. This would
be helpful and very useful. PaceExtendingAtom as it currently is stated
is restrictive without
being useful.
Henry Story
On 13 Jan 2005, at 19:27, Tim Bray wrote:
+1
I wrote it and I still think it's necessary as a bare-minimum measure.
-Tim
On 2 Feb 2005, at 18:09, Antone Roundy wrote:
On Wednesday, February 2, 2005, at 09:49 AM, Henry Story wrote:
Why not go one step further in generality and call the tagline the
summary? Then we will be closer
to the point I had been making in PaceEntriesAllTheWayDown2, and one
step closer
[[
Also, Person Constructs, the atom:head element, and the atom:entry
element
allow the inclusion of foreign markup.
]]
If one could add foreign markup anywhere then the above sentence would
be
redundant.
Henry Story
http://bblfish.net/
On 2 Feb 2005, at 20:01, Joe Gregorio wrote:
How
their cake and eat it too, may be to
allow multiple id tags.
Since an id is an inverse functional relationship between an Entry a
Resource this should
not cause any trouble. In any case there will never be any way you can
limit the number of
names a thing has.
Henry Story
argue that the Atom working group could easily take
a few steps to make the mapping be the identity map.
Henry Story
http://bblfish.net/
On 28 Jan 2005, at 15:14, Danny Ayers wrote:
On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre
[EMAIL PROTECTED] wrote:
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt
Thanks Robert. The Relax NG snippets make a
quickly and easily.
On 27 Jan 2005, at 03:39, Sam Ruby wrote:
Henry Story wrote:
On 26 Jan 2005, at 15:03, Sam Ruby wrote:
[...]
But, now lets examine the statement proposed in
PaceAttributeNamespace. It essentially alerts producers of
something that that they need to be aware of. Now a quesion
On 27 Jan 2005, at 15:28, Bill de hÓra wrote:
Rudeness objection.
One reaps what one sows. [1]
I'm seeing genuine questions
Since you are asking, I'll answer them.
On 26 Jan 2005, at 4:37 pm, Henry Story wrote:
I think your assertion is wrong. If they are consuming or producing
extended Atom [1
On 26 Jan 2005, at 15:03, Sam Ruby wrote:
[...]
But, now lets examine the statement proposed in
PaceAttributeNamespace. It essentially alerts producers of something
that that they need to be aware of. Now a quesion: what do they need
do different with the knowledge that the RDF mapping does
Graham the Robot [1], when real people come and ask me something I'll
talk to them.
Henry
On 26 Jan 2005, at 18:01, Graham wrote:
On 26 Jan 2005, at 4:37 pm, Henry Story wrote:
I think your assertion is wrong. If they are consuming or producing
extended Atom [1]
they will know exactly what
On 18 Jan 2005, at 02:18, Bill de hÓra wrote:
Henry Story wrote:
this implies the following rdf graph
_e -entry- _E
|-id--tag://sometag
|-geo:x-10.1
|-geo:y-57.3
[On a technical point, I would disagree the graph is implied. As I
said earlier, this kind
concerned
that Atom is RDF will annoy people needlessly, which would be a shame
since the work you've been doing on an RDF/OWL view of the Atom format
is both interesting and valuable.
Dan
Henry Story
[1] http://www.intertwingly.net/wiki/pie/AtomOWL
[2] http://www.intertwingly.net/wiki/pie
to create RDF/XML2
where this works out fine.
Henry
On 10 Jan 2005, at 01:29, Robert Sayre wrote:
Henry Story wrote:
[snip]
4) Property attributes
--
both hreflang, href and all the other properties of Link are unique,
and given that they are string literals (subsets of them
://www.w3.org/1999/02/22-rdf-syntax-ns#;
atom:link
atom:hreflang=de
atom:href=http://example.org/de/2003/12/13/Atom03/
/atom:Entry
in the validator you get the following graph:
inline: servlet_77206.gif
which is what I started off with.
Henry Story
On 10 Jan 2005, at 19:11, Henry
I would like to agree with this. I have not had much of a weekend, and
I am not sure I will be able to take so much time off work to put into
this task. I am being paid to work on an open source blog editor, and
I am not sure its ok for me to just spend all my time on this list.
Also the
and outs of this standards process that will know
how to turn that general idea into more specific and acceptable
proposals.
Henry
On 8 Jan 2005, at 21:50, Paul Hoffman / IMC wrote:
At 8:33 PM +0100 1/8/05, Henry Story wrote:
Here is one suggestion I was thinking of to move along, quickly
that out. I
can do with all the help out there :-)
Understand that all I am proposing is a machine readable rewriting of
what the current Atom spec says. That is most of what there is to it.
The rest is just asking for a little good will.
Yours sincerely,
Henry Story
http://bblfish.net/blog
On 9 Jan 2005, at 00:06, Henry Story wrote:
The internet draft I want to propose is an OWL document. I can get
this out tomorrow. It will essentially say everything the current Atom
OWL spec says,
Sorry it is past midnight here at I am typing a little fast.
I meant It will essentially say
spec, or if you really insist, in a separate Draft. That will be
machine interpretable xml, ie: running code.
Good night,
Henry Story
On 9 Jan 2005, at 00:25, Paul Hoffman / IMC wrote:
At 12:06 AM +0100 1/9/05, Henry Story wrote:
The internet draft I want to propose is an OWL document. I
I was just looking closely at the atom:Person class [1] and found some
pretty arbitrary limitations:
- why should a Person only have one e-mail address?
- why should a Person only have one associated url?
It seems to me that one should follow the principle: only impose
limitations that
the RSS2.0 folk. It looks to me that Atom is close
to ending the RSS wars. Time to smoke the peace pipe.
Henry Story
On 18 Dec 2004, at 18:21, Henry Story wrote:
Feed
head
titleExample Feed/title
link href=http://example.org//
updated2003-12-13T18:30:02Z/updated
101 - 200 of 200 matches
Mail list logo
