oralId relation to the same social
security number.
The above can probably be also put in terms of set theory, and
so in terms of rdf graphs. In which case it clearly shows how
rdf can speak about temporal and non temporal identity.
Henry Story
[1] http://www.lyricsfreak.com/m/madonna/86925.html
audi
Thanks Danny, that was a good summary.
+1 for the title from me too.
But I think the deadline for new paces has already passed. >:->
Henry
On 8 Feb 2005, at 13:42, Danny Ayers wrote:
On Tue, 08 Feb 2005 10:40:43 +, Bill de hÓra <[EMAIL PROTECTED]>
wrote:
Henry Story wrote:
If y
On 8 Feb 2005, at 01:49, Roy T. Fielding wrote:
On Feb 7, 2005, at 5:15 AM, Henry Story wrote:
This is true only if you have the [Equivalence ID] interpretation
of the id relation. (Ie you think of id as equivId.)
Yes, and to make myself perfectly clear, that means functional ID,
as you call it
d document)
worked very well for both models.
Henry Story
On 8 Feb 2005, at 00:27, Bill de hÓra wrote:
Henry Story wrote:
I think that the complexity that this proposal is proof of its
failure.
If you look at a Feed document as simply a sliding window view into
the historical state of entries instead
-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 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 of
all
to duplicate the entries 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
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
On 7 Feb 2005, at 14:15, Henry Story wrote:
entry03<-- a directory resource pointed to by the funcId uri
entry03/v1 <-- a directory resource for the previous entry version
entry03/v1/entry.xml <-- the first entry version of the xml
entry03/v1/entry.html <-- the second entry ver
to think the way you do, and in
just as senior or more senior positions than your are. But perhaps
I have missed some important development recently. (I am not being
ironic here though it may sound like it. I really would like to
understand more fully your position.)
Henry Story
or guess what the changing desires
of this working group are (I myself moved from one side 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 bot
I have read your message in full, and I am totally convinced by your
argument. I think the sliding window view is clear, simple and powerful.
(I also think it can easily be modeled in RDF.)
Many +1's from me.
Henry Story
On 6 Feb 2005, at 20:20, Bob Wyman wrote:
The current proposals to defi
6 Feb 2005, at 12:47, Eric Scheid wrote:
On 6/2/05 10:16 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update". Clients can
do simple diffs and work out themselves if the changes
Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update". Clients can
do simple diffs and work out themselves if the changes warrant
a new date. Presumably clients that see that the only change has been
to the white space layout may decide that this
On 6 Feb 2005, at 08:00, Bob Wyman wrote:
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to
try to
rush through something this major at the last moment before a pending
Last
Call.
I agree. Very serious -1 for
defined.
bob wyman
Well to tell the truth I 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
ese can be identified as being different version
of the same entry by their id attribute, just as any other
entry can.
Henry Story
Robert Sayre
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
unt of debating that
this would require would not be worth the effort. The id property
does the job 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 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
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
mean 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 de
again may 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
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
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 conta
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
the
pe of query 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
ple syntax.
Perfection would then be had by making absolutely clear
that the model is a model of the syntax allowed by the relaxng
compliant document, by making sure the relaxng compliant document
also be a rdf/xml document.
Henry Story
http://bblfish.net/
[1] http://www.fakeroot.net/sw/rdf-format
In RDF/model terms the id is a functional property relating an
Entry/Head and a resource (see my AtomOWL pace) It is not strictly
an identity property (which would require it to be functional, inverse
functional, symmetric and transitive)
This therefore gives you no allowance to merge the entries.
[[
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 is
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 to
have 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
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
tioned above, clicking 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, Ti
then we can conclude that 100 == 2*50
Henry Story
On 31 Jan 2005, at 16:25, Henry Story wrote:
One way to get people to have 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 trou
Duh. Sorry. It is a functional property. I explained why myself at
length here:
<http://www.imc.org/atom-syntax/mail-archive/msg12067.html>
All the rest can arguably be thought to be overspecification.
Henry Story
On 1 Feb 2005, at 17:06, Henry Story wrote:
Yes, the id is an inverse func
On 1 Feb 2005, at 16:46, Tim Bray wrote:
On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote:
Over-specification is just too fun. So that would mean I am
required by Atom format to treat two different entries with the id
"http://tbray.org/uid/1000";
as the same entry, even when I received the
ut of business, as people find better
aggregators or editors.
Leaves a bit of space for my Open Source, BSD licenced BlogEd to make
headway.
Henry Story
- Sam Ruby
turn out to be complimentary.
Henry Story
[1] see for example "The Nature of Rationality" by Robert Nozick
http://www.amazon.com/exec/obidos/tg/detail/-/0691020965/
On 1 Feb 2005, at 05:24, Robert Sayre wrote:
Antone Roundy wrote:
My preferences:
+1: Current draft or PaceAggregati
o get people to have 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
om, so close I 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 *hug
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
extend
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
someone said on this list recently that it was
possible
perhaps using xmlschema and treating the content as a special literal. I
just can't find the reference anymore.
Henry Story
[1] http://www.intertwingly.net/wiki/pie/AtomOWL
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
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 t
left as options. In any
case
we are both moving in the same direction.
Henry Story
http://bblfish.net/
[1]
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations
--
Dave
That looks good to me. +1
Henry Story
http://bblfish.net/blog/
On 25 Jan 2005, at 19:45, Danny Ayers wrote:
I have withdrawn the previous suggestion and replaced it with the text
suggested by Antone. Further adjustments/refinements welcome.
The key idea is anchor the attribute names in the Atom
Are we speaking about PaceEntriesAllTheWayDown2 here?
Because if we are I am still behind it, (though it may need adapting as
it was written
for the previous version of the spec). I also think we may get a +1
from Roy Fielding,
as I think this is just step 1 of his proposal. I also think we could
don't see is how you can object to a Pace that does not affect
anything you need on grounds that you object to the aims the Pace is
trying to fulfill, when those aims are central to the Atom working
group.
Henry Story
On 25 Jan 2005, at 03:08, Joe Gregorio wrote:
On Tue, 25 Jan 2005 02:
On 24 Jan 2005, at 22:38, Sam Ruby wrote:
Henry Story wrote:
We are all working together on the proposal, in an iterative fashion.
This is very similar to the way one develops software projects in
Agile
or Extreme programming methodology. First one starts with a
prototype.
One gets the major
is for this to have minimal
impact on the
spec. So if you don't care about writing or parsing atom extension,
then you need not worry.
Henry Story
On 25 Jan 2005, at 02:25, Joe Gregorio wrote:
-1 Ick.
The only example given of a case where this may cause others problems
is RDF, and I thoug
detailed text, can get going debating and refining that.
I would be very thankful if someone with more specification experience
could get
it into the correct final format.
Yours sincerely,
Henry Story
[1] http://www.intertwingly.net/wiki/pie/AtomAsRDF_PaceAttributesNS
On 24 Jan 2005, at 18
On 24 Jan 2005, at 17:35, Tim Bray wrote:
On Jan 24, 2005, at 1:02 AM, Henry Story wrote:
Text close to the following should appear in the spec (please make
more precise)
"Processors should interpret unprefixed attributes in atom
namespaced elements to be in the atom namespace"
W
on, and
perhaps notice an oversight.
Henry Story
http://bblfish.net/blog/
[1] http://www.intertwingly.net/wiki/pie/AtomAsRDF
On 24 Jan 2005, at 04:12, Martin Duerst wrote:
At 03:07 05/01/23, Tim Bray wrote:
>
>On Jan 22, 2005, at 6:24 AM, Bill de h~{%b~}ra wrote:
>
>> 1. specify tha
I'll put all solutions up on the Pace when I get time.
I think 1. is good enough myself. I imagine that perhaps a future
version of XML will by default put non namespaced attributes in the
default namespace, no? In which case things will work out ok in the
long term.
If there are any other solu
I think that is specified in the IdentityConstruct section of the spec.
In the OWL I just take that to be a RDF Resource.
Henry
On 19 Jan 2005, at 11:18, Danny Ayers wrote:
I don't know whether this is a little editorial oversight or something
I missed/misremember - wasn't it agreed that the conten
How is this coming along?
I think the current spec really would do with some good simplification.
We have
RSS1.1 to look at now, at it does look a hell of a lot simpler. (Don't
want to
start a RSS1.1 thread here please)
I think the easiest way to get what you want is a 2 step procedure:
1. Mer
Ah. It looks like the RSS1.0 people are moving along. Their new format
even
has a small OWL file to go with it. I thought we could better them by
having
one first!
Henry Story
On 18 Jan 2005, at 15:00, Sean B. Palmer wrote:
I'm pleased to announce the release of RSS 1.1: a bugfix version o
On 18 Jan 2005, at 01:26, Danny Ayers wrote:
On Mon, 17 Jan 2005 23:38:50 +0100, Henry Story
<[EMAIL PROTECTED]> wrote:
Take for example the following extension proposed recently
tag://sometag
10.1
57.3
...
this implies the following rdf graph
_e
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-->
|-geo:x->"10.1"
|-geo:y->"57.3"
[On a technical point, I would disagree the graph is implied. As I
said
end up with a format
that is extensible and even better defined than RSS1.0
Henry Story
On 17 Jan 2005, at 22:43, Bill de hÓra wrote:
Incidently the name AtomIsRDF isn't as problematic as the latent
assumption - that Atom is some of kind of degenerate or special case
of RDF. My opinion is that's a losing strategy if the goal is wider
adoption of RDF.
ed. The aim is to make
the
rdf as invisible as possible to anyone other than atom extension
writers. If we
have to bring out difficult rdf tools, so be it.
Henry Story
On 17 Jan 2005, at 21:15, Danny Ayers wrote:
I think there may be a very clean mapping of the content by simply
taking the typ
On 17 Jan 2005, Walter Underwood wrote:
Call it "AtomAsRDF".
That is indeed a much better name. Ok, off to change the page again...
On 17 Jan 2005, at 20:38, Sam Ruby wrote:
Henry Story wrote:
Yes, very good point. I have created a new Page called AtomRDF [3],
whose aim
is to track wha
an RDF enthusiast, I find the name problematic. So I'm
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.inte
with RDF. As you
will see there
is not a lot of difference really. So this should harm no one, but make
it much easier to extend atom in a failsafe way.
Henry Story
[1] http://www.intertwingly.net/wiki/pie/AtomOWL
[2] http://www.intertwingly.net/wiki/pie/AtomIsRDF
13T18:30:02Z"
Interestingly enough the graph above I get is (nearly) exactly the same
as the triple model
I get from parsing the closest rdf/xml I could get that resembles the
atom example xml:
xmlns:atom="http://purl.org/atom/ns#draft-ietf-atompub-format-03";
xmlns:
res one to make a little shift in your thinking.
Think of the id as your constant Entry over time that just points via
the
1/id relationship to all the Entry Versions out there (which the common
mortals thing of as Entries). It makes sense when one gets used to it
and is very powerful :-)
Henry Stor
Is there a DTD available for the current spec?
Or something similar?
Otherwise how could I specify the equivalent of
in the spec?
I suppose we just say something like:
the head element has a hidden default attribute of rdf:parseType with a
fixed value of "Resource"
Henry Story
Just found this mail and thought it worth replying to. It points out a
little bug
with the Ontology I just released lately. I made the entry id inverse
functional.
That won't do.
If id is inverse functional, then given two entries with the same id
_f1a->
|---entry--> _e1 ---a->
2/22-rdf-syntax-ns#";>
atom:hreflang="de"
atom:href="http://example.org/de/2003/12/13/Atom03"/>
in the validator you get the following graph:
<>
which is what I started off with.
Henry Story
On 10 Jan 2005, at 19:11, Henry Story wrote:
Ok, I give u
ds 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 th
On 7 Jan 2005, at 21:56, Robert Sayre wrote:
Henry Story wrote:
The question is exactly how should the interesting discovery that an
Atom document is an RDF document [Ø] be used to fulfill the charter
requirements on extensibility?
Have you figured out a way to deal with this:
Thanks for the
editorial process.
Henry Story
[1] see the UML diagrams here
http://www.imc.org/atom-syntax/mail-archive/msg04494.html
[2] http://www.intertwingly.net/wiki/pie/PaceEntriesAllTheWayDown2
On 10 Jan 2005, at 00:20, Roy T. Fielding wrote:
Personally, what I would change in the format is elimination
of
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 propo
formed Atom file be a file that is an rdf graph that uses
the above ontology.
If we can get the ontology to be a formalization of the spec, then it
will be very simple to explain how to extend Atom.
Henry Story
[1] http://protege.stanford.edu/
Atom.n3
Description: Binary data
Atom.owl
atom 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
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
along and write 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://bblfis
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 and
whole of which can be mapped into an RDF graph.
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html
On 8 Jan 2005, at 19:49, Tim Bray wrote:
[On behalf of Paul and myself:]
The opinion has been forcefully expressed that Atom should adopt an
extensibility framework based partly
On 8 Jan 2005, at 16:47, Roger B. wrote:
I think this is a very nice example, and will show the power of seeing
atom as RDF.
Henry: I hope it isn't too depressing to know that, at least for this
individual, it really doesn't. To me, you've just sketched out a
solution in search of a problem... the
nformation.
Ok. So what can we deduce from the above:
- it is possible to have nonsensical but well formed xml
- well defined Ontologies can help create extensions to atom that
make sense
- These ontologies then allow certain deductions to be made by in
the know software that can b
topic.
Henry Story
[Ø] though it still remains to be formally proven
[1] A similar question was just asked by Danny Ayers
http://www.imc.org/atom-syntax/mail-archive/msg11918.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg11909.html
On 6 Jan 2005, at 19:27, Paul Hoffman wrote [2]:
At 6:
spend too much
time on it. Also I would probably find a lot of people a lot more
knowledgeable than me to help on this task if there was a declared
interest.
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html
I later found ways around most (all?) of the problems
extensibility problem.
I don't know what more I can do.
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html
On 6 Jan 2005, at 15:50, Danny Ayers wrote:
On Wed, 05 Jan 2005 17:26:02 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
This represents the result of discussions b
ation restricting the inverse functional email
and uri
properties to 1
Do we need a Pace for Dan Brickley's suggestion?
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11872.html
On 4 Jan 2005, at 19:27, Brett Lindsley wrote:
I appreciate the interesting discussion alt
27;ll go through the process of step by step showing how one can
get to an atom xml format
from first principles.
Henry Story
[1] http://www.schemaweb.info/schema/SchemaDetails.aspx?id=215
On 4 Jan 2005, at 16:06, Henry Story wrote:
I think that the simplicity of atom:Person is fine. I have n
uri. Perhaps this would be a good idea for a improvement to the spec?
Henry Story
[1] http://xmlns.com/foaf/0.1/#term_Agent (In fact I think that we
should use Agent instead of Person, as it is quite possible that
robots, or multi-person organizations be creating blog entries or
feeds.
On 4 Jan
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 are
erience to declare Atom as their successor format,
and Atom to come clean on its extensibility requirement from the
charter. The nice thing is that this is done whilst taking on board all
the criticism from the RSS2.0 folk. It looks to me that Atom is close
to ending the RSS wars. Time to smoke th
John Doe
Atom Powered Robots Run Amok
vemmi://example.org/2003/32397"/>
2003-12-13T18:30:02Z
As a result we have something that is very very very close to our
current Atom syntax.
Since we have a format
Thinking about this a little more I don't think I need to stop the
PaceHeadInEntry.
PaceEntriesAllTheWayDown2 seems to me to be compatible with it, though
from my current understand, perhaps just a little unnecessary.
Henry
On 23 Nov 2004, at 16:04, Henry Story wrote:
Let me summ
ot that an elegant solution exists that takes into account this
overwhelming similarity.
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11577.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg11604.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg11673.html
On 23 Nov 2004
It seems to me that PaceEntriesAllTheWayDown2 with atom:origin is a
good counter proposal to PaceHeadInEntry. It also simplifies the spec a
lot more. The two should at least be compared and evalutated on their
merit.
It may not be obvious from the discussion but I would see the following
peopl
On 22 Nov 2004, at 15:33, Henry Story wrote:
- a Link that points to the the Dynamic Feed document which is the
*start* of the
feed. This document is the one that is usually considered to be the
feed.
- a Link that points to the *next* newest feed document, which
contains the next entry
Mark, that the above model is a good representation of
your proposal?
Henry Story
[1]
http://bblfish.net/work/atom-owl/2004-08-12/
blogexample.html#entry.2004-08-12-2035.n3
[2] Martin Fowler, "UML Distilled, Second Edition" chapter 6, "Multiple
and Dynamic Classification"
able to get this
information, but there really is not guarantee that I will be able to
do it.
Henry Story
[1] https://bloged.dev.java.net/
[2] http://www.rollerweblogger.org/
On 21 Nov 2004, at 17:46, Mark Nottingham wrote:
"Reconstructing Feed State", seems to me to be expecting rathe
201 - 299 of 299 matches
Mail list logo
