* Eric Scheid <[EMAIL PROTECTED]> [2005-08-11 07:25]:
>
> On 11/8/05 3:05 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>
> > What scenario exists wherein it would be *more* desirable to
> > provide *only* a dereferencable location but *not* an ID?
> > When would it be *wiser* to *rely* on a poi
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-11 07:40]:
> Of course it's "related". All links in an entry point to
> related resources, that's the very definition of a link. We
> also know what the nature of the relationship is (it's in reply
> to that resource), so it doesn't hurt to specify that.
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-06 05:40]:
> either that or a flag that says "this is dereferenceable", but
> that is ugly and doesn't let the publisher have a link with
> both.
>
> would it be useful? google does interesting things by crawling
> links, so do many other link crawling t
Wednesday, August 10, 2005, 11:33:46 PM, Robert Sayre wrote:
> On 8/10/05, David Powell <[EMAIL PROTECTED]> wrote:
>> I think that it is pretty clear, but as Tim disagrees, I think that
>> this is a good indication that we need clarification.
> I think it's good indication that you've argued wi
Wednesday, August 10, 2005, 11:12:30 PM, you wrote:
> Dave: I think I see what you're getting at... correct me if I'm wrong.
> So I decide that my aggregator is going to look for unknown Simple
> Extensions in Atom feeds and display them as a table of name/value
> pairs at the bottom of every e
I said:
> I might have misinterpreted your comment, but I'm arguing with Tim for
> saying that SEE's CAN contain relative refs and no clarifification is
> needed, and with you for saying that SEE's CANNOT contain relative
> refs and no clarification is needed. There's a word for that :)
I overs
On Thu, 11 Aug 2005, A. Pagaltzis wrote:
>
> * James M Snell <[EMAIL PROTECTED]> [2005-08-09 07:25]:
> > The second feed illustrates the two forms of the in-reply-to
> > element. The dereferenceable form uses the href attribute to
> > locate the entity being responded to.
>
> I am still strongly
* Justin Fletcher <[EMAIL PROTECTED]> [2005-08-11 17:10]:
> By all means require any reference to a Atom document to supply
> an identifier, but requiring it on all references would make it
> impossible to fulfill on some documents.
Yeah; again, I’ve conceded the point. I still don’t particularly
Greetings again. I think we have rough consensus on "emitting with
whitespace around IRIs and dates is an error" and "we should warn
folks that people might emit errors here because this is somewhat
subtle".
If that is true, I propose that, just before section 3.1 (at the end
of the introdu
* Paul Hoffman <[EMAIL PROTECTED]> [2005-08-12 06:15]:
> Note that there MUST be no whitespace in a Date construct or in
> any IRI. Some XML-emitting implementations erroneously insert
> whitespace around values by default, and such implementations
> will emit invalid Atom.
+1
Minor niggle: I’d
--On August 11, 2005 9:04:21 PM -0700 Paul Hoffman <[EMAIL PROTECTED]> wrote:
> Note that there MUST be no whitespace in a Date construct or in any IRI. Some
> XML-emitting implementations erroneously insert whitespace around values by
> default, and such implementations will emit invalid Atom.
+1 on this with the "MUST NOT be" suggestion
Walter Underwood wrote:
--On August 11, 2005 9:04:21 PM -0700 Paul Hoffman <[EMAIL PROTECTED]> wrote:
Note that there MUST be no whitespace in a Date construct or in any IRI. Some
XML-emitting implementations erroneously insert whitespace arou
On 12/8/05 2:29 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> Note that there MUST be no whitespace in a Date construct or in
>> any IRI. Some XML-emitting implementations erroneously insert
>> whitespace around values by default, and such implementations
>> will emit invalid Atom.
>
> +1
>
13 matches
Mail list logo
