Tim Bray wrote:
> 2. We are close to RSS2 feature-compatibility, we either adopt
> image & enclosure or make a conscious decision not to.
There are other bits of RSS2 that should be seriously considered --
even if they aren't widely used. For instance, the RSS2 element
which contains a PI
As Robert Sayre recently wrote:
>DSig and XMLEnc are in
core.
>http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.7
However, the text says:
“The document element of an Atom
document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry
Docum
I really don't want to be going down the road of requiring HTTP header
equivalents in the Atom feed, etc. All I want is the ability to
specify a hash of whatever it is that is being linked to. It could
work in both link and content elements and one could easily use the
Content-MD5 header to veri
Bob Wyman wrote:
2.I've been thinking that I might include an atom:summary element that
contained a textual version of the XML data carried in the content field.
However, it appears that most aggregators today display either the summary
or the content but don't display both...
The same is tr
On Saturday, January 8, 2005, at 04:49 PM, Bob Wyman wrote:
One quick comment--would not the above XML place in the
namespace "http://pubsub.com/xmlns"; rather than the Atom namespace?
I'd think you need something like this:
On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote:
I doubt anyone reading Tim's recent posts on the subject of
extensibility could come to any conclusion other than that he is
vehemently opposed
I've decided I just don't know. Henry says we need to do nearly
nothing, and a few days back I proposed sa
On 9/1/05 7:28 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> I require this functionality in . There is aboslutely
> no way I'm initiating 20 HTTP requests (even HEADs) each time the feed
> is reloaded.
that's what the /feed/entry/modified date is for.
e.
On Saturday, January 8, 2005, at 08:00 AM, Henry Story wrote:
Now the problem with the graph above, is that it does not make sense to
assign a geo location to an entry. This will probably not be allowed
by the geo ontology, which will probably specify some location class
to be the the subject of
On Sun, 09 Jan 2005 00:18:37 +, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Look, the point is this. Those arguing from the RDF side of the house do [not]
> mean what you mean by extensible. Furthermore, what is meant there by
> extensible hasn't been demonstrated (in my mind) as a requirement
On Sat, 8 Jan 2005 20:49:55 +, Graham <[EMAIL PROTECTED]> wrote:
> Well, for that example, it's not so necessary. But I've heard of one
> suggested usage being:
>
>
>
> Which would require reloading to maintain feature parity with
> non-external content.
How about putting HTTP etags direct
Robert Sayre wrote:
Well, Content-Length lives in the attributes as "length", but I don't
think we need to make a home for every HTTP header. Content-MD5 will
work just fine; it would probably be wise to send a HEAD request before
automatically downloading a giant mp3. Furthermore, you'll get a
On Sat, 8 Jan 2005 17:26:14 -0500, Scott Hollenbeck <[EMAIL PROTECTED]> wrote:
> > No-one gains anything from overly protracted discussion. But
> > I don't seen any extraordinary circumstances that might
> > justify the imposition of cloture. Is there something related
> > to the (still unexplaine
Tim Bray wrote:
On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote:
My answer to this question is that Atom doesn't have a model in terms
of being able to talk about extension so there's no point discussing
it. Extensibility is probably out of scope for the format.
I'm not going to let that go unch
Bill de hÓra wrote:
Look, the point is this. Those arguing from the RDF side of the house do
mean what you mean by extensible. Furthermore, what is meant there by
Dammit. Sorry, that should be, those arguing from the RDF side of the
house do *not* mean what you mean by extensible.
cheers
Bill
On Friday, January 7, 2005, at 09:33 PM, Eric Scheid wrote:
On 8/1/05 11:03 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
(This seems so
intuitively obvious that I wouldn't think people would make XML that
didn't work this way, but from the sound of it, there are examples out
there of XML where c
At PubSub, we’re beginning to put together a live feed of
earthquake and tsunami information in the hope that by making this information
more widely and rapidly disseminated, we’ll be able to prevent at least a
tiny amount of the troubles such as recently happened in the Indian Ocean. In
co
I can't do everything simultaneously. Tomorrow I will give you a first
version of an OWL document that will map the current atom spec. Can you
give me the current namespace for the draft atom spec I am supposed to
be working to? This is so the atom OWL document can describe the
properties of th
On Saturday, January 8, 2005, at 02:59 AM, Danny Ayers wrote:
Say your system is aggregating material from two sensors, and you get
the following, one from each:
http://123
2005-02-02
10.1
57.3
http://123
2005-02-03
7
It isn't clear how these should be merged - does the entry wit
At 12:06 AM +0100 1/9/05, 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, but in machine readable form.
An OWL document is not an Internet Draft. If you cannot create 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 essentially say e
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, but in machine readable form.
All that is required then is that the Atom IETF document this working
group is working on have some language d
At 10:54 PM +0100 1/8/05, Henry Story wrote:
The IETF document I mentioned is the one this mailing list is
working on developing.
Then you didn't understand Tim's message. He meant a *new* Internet
draft, not a change to the current draft (unless the change is a few
sentences). From your list of
At 11:03 PM +0100 1/8/05, Danny Ayers wrote:
I am optimistic a compromise on the extensibility/RDF issue can be
reached in the given time frame,
Good!
but find the imposition of such a
short period a bit extreme.
The WG has been discussing this for *months*. The fact that the
chairs have put an e
On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote:
No-one gains anything from overly protracted discussion. But I don't
seen any extraordinary circumstances that might justify the imposition
of cloture. Is there something related to the (still unexplained)
"deadline" mentioned in Tim's recent post?
Tim
> No-one gains anything from overly protracted discussion. But
> I don't seen any extraordinary circumstances that might
> justify the imposition of cloture. Is there something related
> to the (still unexplained) "deadline" mentioned in Tim's recent post?
I'm not sure that I understand why yo
On Sat, 8 Jan 2005 13:48:47 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2005, at 2:21 AM, Danny Ayers wrote:
> > Perhaps I wasn't clear enough. XML has containment. Individual
> > specifications may assign it semantics. RDF/XML assigns it semantics
> > corresponding to the RDF mo
I'm not going to argue the point here any further, but feel something
has to be said.
I am optimistic a compromise on the extensibility/RDF issue can be
reached in the given time frame, but find the imposition of such a
short period a bit extreme. It isn't that there hasn't been
considerable work
The IETF document I mentioned is the one this mailing list is working
on developing. The four points I listed are starting points for a
couple of small additions to the Atom IETF document and their relation
to a to be written OWL Ontology. There are I am sure people more
familiar with the ins a
On Jan 8, 2005, at 2:21 AM, Danny Ayers wrote:
Perhaps I wasn't clear enough. XML has containment. Individual
specifications may assign it semantics. RDF/XML assigns it semantics
corresponding to the RDF model. Without either the individual
specification's definition, or a generalised interpretatio
On Sat, 08 Jan 2005 10:13:57 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote:
>
> > My answer to this question is that Atom doesn't have a model in terms
> > of being able to talk about extension so there's no point discussing
> > it. Extensibility i
Graham wrote:
Well, for that example, it's not so necessary. But I've heard of one
suggested usage being:
Which would require reloading to maintain feature parity with
non-external content.
http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2
"If the value of type
At 8:33 PM +0100 1/8/05, Henry Story wrote:
Here is one suggestion I was thinking of to move along, quickly and
seamlessly I hope.
All that seems fine, but your list is neither a Pace nor an Internet
draft, and is therefore not in line with what Tim and I asked for.
Given that you talk about an
Well, for that example, it's not so necessary. But I've heard of one
suggested usage being:
Which would require reloading to maintain feature parity with
non-external content.
Graham
smime.p7s
Description: S/MIME cryptographic signature
Graham wrote:
I require this functionality in . There is aboslutely
no way I'm initiating 20 HTTP requests (even HEADs) each time the feed
is reloaded.
Can you explain why you would need to initiate HTTP requests for
? I don't understand.
...
...
...
Robert Sayre
I require this functionality in . There is aboslutely
no way I'm initiating 20 HTTP requests (even HEADs) each time the feed
is reloaded.
Graham
smime.p7s
Description: S/MIME cryptographic signature
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray
> Sent: Saturday, January 08, 2005 10:49 AM
> To: 'Atom WG'
> Subject: Closure on Extensibility & RDF
>
> [On behalf of Paul and myself:]
>
> The opinion has been forcefully expressed that Atom
Bill de hÓra wrote:
http://example.com/somefile.mp3";
hash="{generated_hash_value}"
hashalg="{uri_identifying_the_hash_algorithm_used" />
The hash and hashalg attributes would be optional but MUST appear
together.
Thoughts? (If we have more than two people respond favorably
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill de hÓra
> Sent: Saturday, January 08, 2005 8:15 AM
> To: 'Atom WG'
> Subject: Re: Atom extensibility, RDF, and GRDDL
--snip--
> Sam I'm tempted to use the 'put in the implementors guide' - calling
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill de hÓra
> Sent: Saturday, January 08, 2005 8:04 AM
> To: 'Atom WG'
> Subject: Re: Atom extensibility
--snip--
> I'm +1 on not requiring an RDF mapping for Atom. Those of us that like
> to use RDF
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray
> Sent: Saturday, January 08, 2005 10:14 AM
> To: Bill de hÓra
> Cc: 'Atom WG'
> Subject: Re: Atom extensibility, RDF, and GRDDL
--snip--
> The people who insist that you have to have to buy in
Here is one suggestion I was thinking of to move along, quickly and
seamlessly I hope.
1. Atom will have an associated machine readable OWL document that
defines each
of the objects and properties described in the Atom syntax spec,
with language
that mirrors that of the spec.
1.1 Th
[On behalf of Paul and myself:]
The opinion has been forcefully expressed that Atom should adopt an
extensibility framework based partly or wholly, directly or indirectly,
on RDF. This idea is not unreasonable on the face of it. Thus, the
time has now come to put this into a concrete proposal.
On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote:
My answer to this question is that Atom doesn't have a model in terms
of being able to talk about extension so there's no point discussing
it. Extensibility is probably out of scope for the format.
I'm not going to let that go unchallenged. The abi
http://example.com/somefile.mp3";
hash="{generated_hash_value}"
hashalg="{uri_identifying_the_hash_algorithm_used" />
The hash and hashalg attributes would be optional but MUST appear together.
Thoughts? (If we have more than two people respond favorably to this,
I'll write up
David Powell wrote:
But you can't then expect to merge two different instances of the
entry under this model using simple RDF graph merging, because the
model is an over-simplification.
Eg: If you merged:
http://123
2005-02-03
7
and
http://123
2005-02-04
7.5
... you would get:
ht
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
Tim Bray wrote:
Would you be satisfied with a paragraph that says that those who extend
Atom may do so by putting in namespaced elements, and that such
elements, when the information they contain is relevant to an entry,
SHOULD appear as a child of atom:entry?
Replace 'extend' with 'add informat
Robert Sayre wrote:
GRDDL addresses the concerns of some participants, but I don't think it
addresses the issues being raised by David Powell[0] and myself[1].
I think our question is this: where are extension elements part of the
Atom model, and where do they constitute an extension of the Atom
Sam Ruby wrote:
In the case of RDF, there exists a standard means to associate a
document with a mapping. This standard is called GRDDL. [1]
[...]
Meanwhile, it would not be harmful to mention this one element or
attribute (anybody have a preference) in the specification.
It's not clear to me t
Tim Bray wrote:
I think that the charter requirements on extensibility will be filled
adequately with PaceExtendingAtom. I think they would be filled still
better by adopting PaceMustUnderstandElement, but apparently others are
unconvinced. Extensibility via a mapping to RDF seems to me to add
David Powell wrote:
I'd say that the most useful basic features of RDF are:
1) Property names are namespaced for extensibility.
2) Important entities can be assigned global identifiers so that they
can be referred to externally.
[...]
We have 1), and 2) near enough already in Atom.
David,
I've s
> 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... there are far, far easier ways of
getti
I think this is a very nice example, and will show the power of seeing
atom as RDF. If we accept that the atom syntax is an RDF syntax [Ø]
then we can draw the two entries in the ascii graph notation [1] as
follows.
_f1 ---is a--->
|head>
|entry---> _e1 --is a--->
On Sat, 8 Jan 2005 12:00:19 +, David Powell <[EMAIL PROTECTED]> wrote:
Its a tradeoff between flexibility
> and complexity.
Indeed. There was recently some coverage on-list about using a richer
model (in RDF), specifically to preserve provenance.
Cheers,
Danny.
--
http://dannyayers.com
Saturday, January 8, 2005, 9:59:12 AM, you wrote:
> Say your system is aggregating material from two sensors, and you get
> the following, one from each:
>
> http://123
> 2005-02-02
> 10.1
> 57.3
>
>
> http://123
> 2005-02-03
> 7
>
> It isn't clear how these should be merged
On Fri, 7 Jan 2005 17:57:35 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> And it also says
>
> 7 Sharp-eyed readers...
I was only providing an example for demonstration purposes. Broad brush strokes.
> > _:entry prism:embargoDate "2005-02-15" .
> >
> > The embargoDate is unambiguously
On Fri, 7 Jan 2005 16:39:41 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote:
>
> On Friday, January 7, 2005, at 03:53 PM, Danny Ayers wrote:
> > On Fri, 7 Jan 2005 14:21:49 -0700, Antone Roundy
> > <[EMAIL PROTECTED]> wrote:
> >> Could you give an example of something useful that a real world
> >
57 matches
Mail list logo
