RE: PaceSimpleLanguageTagging status

I am strongly opposed to PaceSimpleLanguageTagging. Atom should not repeat the mistake made by RSS V2.0 and others in inventing new and inadequate mechanisms for language tagging. xml:lang is the appropriate means to handle language tagging. The Pace identifies some "costs" of the xml:lang mecha

Re: AtomPubIssuesList for 2005/01/24

Paul Hoffman wrote: At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote: Why don't you just invent a status of "incomplete" and leave them off the table until completed? It doesn't make sense to close issues that are not resolved one way or another. It does make sense this late in the process. As we

Re: PaceIRI status

Tim Bray wrote: If there were no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. -Tim I saw some concerns (with which I agree) that requiring the presence of an IDN library is problematic. As far as I can tell, it's likely to be ignored by

Issues with draft-ietf-atompub-format-04

* 3.1.1 "type" Attribute I was wondering how I can include MathML in Atom posts or simple SVG fragments. If there are extension mechanisms available, shouldn't 3.1.1 refer to those? * 3.5.1 "rel" Attribute Why are the only values defined "alternate" and "related"? I have implemented "via" for a lon

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Mon, 24 Jan 2005 21:35:37 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: > > Danny Ayers wrote: > > > > One thing I'm not sure about - where it currently says "Atom > > processors", perhaps that would be better as merely "Atom consumers". > > For the reasons Sam gave, we don't really want extra va

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Tue, 25 Jan 2005 04:33:35 +0100, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > * Danny Ayers wrote: > >To be inserted: > >{{{ > >Section 2. Atom Documents > > > >Atom processors MAY interpret unprefixed attribute names as their > >namespace-qualified equivalents. > >If they do, then all Atom a

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Tue, 25 Jan 2005 04:47:49 +0100, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > > * Sam Ruby wrote: > >I'm a bit concerned about precedence rules (what happens if there is an > >href attribute *AND* an atom:href attribute?). What makes most sense > >here is for a prohibition disallowing such i

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

* Danny Ayers wrote: >> This does not make much sense to me, it is either not possible to write >> a test case for the first requirement in which case this would be an im- >> plementation detail which is out of scope of the specification, or it is >> possible to write such a test case in which cas

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

* Danny Ayers wrote: >Again, I don't think this a problem when the >no-namespace/atom-namespace mapping is only an option for consumers - >unless I'm missing something? I am not sure what you consider a "consumer" in this context, pointer? -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bj

Re: Issues with draft-ietf-atompub-format-04

(CC'ing the list.) * 3.1.1 "type" Attribute I was wondering how I can include MathML in Atom posts or simple SVG fragments. If there are extension mechanisms available, shouldn't 3.1.1 refer to those? 3.1 is Text Constructs, which are used for inside the element ... 4.2.1 "atom:title" Element 4.

Re: PaceIRI status

At 17:16 05/01/25, Julian Reschke wrote: >Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs Every URI is an IRI by definition. So all URIs that are in use can be used with Atom without any problems even if the spec says we use IRIs. Replacement

Re: PaceDateofSubject status

Eric Scheid wrote: That message of yours talks about "dateline", a similar concept but one which was discussed quite some time before DateOfSubject was proposed (July, vs September) I could not quite see the difference between DateLine and DateOfSubject... Is there any significant difference? Reg

Re: PaceIRI status

Martin Duerst wrote: At 17:16 05/01/25, Julian Reschke wrote: >Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs Every URI is an IRI by definition. So all URIs that are in use can be used with Atom without any problems even if the spec says we

Re: PaceSimpleLanguageTagging status

(BHello Bjoern, (B (BFor more details, please see my earlier message at (Bhttp://www.imc.org/atom-syntax/mail-archive/msg12198.html. (BPlease comment on the specific points mentioned there. (B (BRegards, Martin. (B (BAt 16:15 05/01/25, Bjoern Hoehrmann wrote: (B > (B >* Martin Duerst

Re: PaceAttributesNamespace (was Re: AtomAsRDF_PaceAttributesNS)

On Tue, 25 Jan 2005 12:22:24 +0100, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > If this implementation detail is exposed to the user, it would seem > reasonable to consider such a software a Atom-to-something-else con- > verter; you would thus seem to propose the introduction of conformance > r

Re: PaceIRI status

Julian Reschke wrote: The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HTML href attribute wi

Re: PaceIRI status

* Julian Reschke wrote: >The big difference here is that XMLNS uses IRIs/URIs as identifiers and >only for that. However, what is an XSLT that transforms Atom content to >HTML supposed to do when it encounters a IRI which isn't a legal URI? http://www.w3.org/TR/xslt#section-HTML-Output-Method

Re: PaceIRI status

Bjoern Hoehrmann wrote: * Julian Reschke wrote: The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? http://www.w3.org/TR/xslt#section

Re: PaceAttributesNamespace status

Joe Gregorio wrote: -1 Ick. The only example given of a case where this may cause others problems is RDF, and I thought we were going to have a non-normative Atom -> RDF XSLT? Are there other cases I am unaware of? I don't think this is specific to RDF or Atom. 1. Sam mentioned precedence rules (hr

Re: PaceIRI status

Martin Duerst wrote: At 17:16 05/01/25, Julian Reschke wrote: >Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs Every URI is an IRI by definition. So all URIs that are in use can be used with Atom without any problems even if the spec says we

Re: PaceEnclosuresAndPix status

Tim Bray wrote: Would anyone be upset if I updated the draft to say an aspect ratio of 2 (horizontal) to 1 (vertical)? -Tim Not me. +1 cheers Bill

Re: PaceIRI status

* Julian Reschke wrote: >>>The big difference here is that XMLNS uses IRIs/URIs as identifiers and >>>only for that. However, what is an XSLT that transforms Atom content to >>>HTML supposed to do when it encounters a IRI which isn't a legal URI? >> >> http://www.w3.org/TR/xslt#section-HTML-Ou

Re: PaceIRI status

At 22:29 05/01/25, Julian Reschke wrote: >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HT

Re: PaceIRI status

Bjoern Hoehrmann wrote: * Julian Reschke wrote: The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? http://www.w3.org/TR/xslt#section-

Re: PaceIRI status

Martin Duerst wrote: At 22:29 05/01/25, Julian Reschke wrote: >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it c

Re: PaceAttributesNamespace status

Bill de hÓra wrote: Joe Gregorio wrote: -1 Ick. The only example given of a case where this may cause others problems is RDF, and I thought we were going to have a non-normative Atom -> RDF XSLT? Are there other cases I am unaware of? I don't think this is specific to RDF or Atom. 1. Sam mentioned

Re: PaceIRI status

At 23:59 05/01/25, Julian Reschke wrote: >Martin Duerst wrote: >> At 22:29 05/01/25, Julian Reschke wrote: >> >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a

Re: PaceAttributesNamespace status

[cc'd to Robert] Sam Ruby wrote: Bill de hÓra wrote: 1. Sam mentioned precedence rules (href and atom:href). atom:href is not part of the specification. That should be made clearer ;) 2. It's not clear how you'd pepper atom elements with attributes (ie do we spec that you must put your extra at

PaceFeedLink

I like the proposal in general though I wonder why an absolute URI is required. Since aggregators already have to support xml:base it would be logical to make that a relative URI. Also, could an additional requirement be added. Namely that aggregators use the URI in |rel="self"| to check for t

Re: PaceIRI status

At 23:11 05/01/25, Julian Reschke wrote: > >Bjoern Hoehrmann wrote: >> http://www.w3.org/TR/xslt#section-HTML-Output-Method >> The html output method should escape non-ASCII characters in URI >> attribute values using the method recommended in Section B.2.1 of >> the HTML 4.0 Recommendation.

Re: PaceFeedLink

On 26/1/05 2:16 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: > I like the proposal in general though I wonder why an absolute URI is > required. One of the intended uses is for when a browser downloads a feed resource to disk, and then hands that file to an atom handler application. Once t

Re: PaceFeedLink

Since aggregators already have to support xml:base it would be logical to make that a relative URI. A relative URI would only be useful if there is in fact an xml:base in effect. With no xml:base then the relative reference would be useless. We could either write some spec text for that unusua

Re: PaceDateofSubject status

On 26/1/05 12:24 AM, "Sascha Carlin" <[EMAIL PROTECTED]> wrote: > Eric Scheid wrote: >> That message of yours talks about "dateline", a similar concept but one >> which was discussed quite some time before DateOfSubject was proposed (July, >> vs September) > > I could not quite see the differenc

Re: PaceEnclosuresAndPix status

+1 from me, I'm happy to see this added! On 24-Jan-05, at 7:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim [-] Ray Slakinski GnuPG Fingerprint: C8AD 4847 2DA8 3469 0

Re: PaceFeedLink status

Tim Bray wrote: Not yet taken up by the WG, depends on the discussion that comes with this call. Same rules as all the others: there has to be a positive WG consensus that each adds to the base specification. -Tim +1.

Re: Questions about -04

On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: 2. Why MUST a feed point to an alternate version. [...] I'm -1 on removing this restriction. I thought we came to a sort of consensus that the link should be optional. Or was that only for atom:entry? Anyway, I think both

Re: Issues with draft-ietf-atompub-format-04

On Tue, 25 Jan 2005 09:59:08 +0100, Anne van Kesteren <[EMAIL PROTECTED]> wrote: This was about it. I hope it is of some use. I share all your concerns and issues and hope they will be addressed properly before the format is finalized. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/qua

Re: AtomPubIssuesList for 2005/01/24

At 9:12 AM +0100 1/25/05, Julian Reschke wrote: Aren't you planning to do a working-group last call before that? We're planning to ask for editorial changes after the next draft. Those are also welcome now on the current draft. --Paul Hoffman, Director --Internet Mail Consortium

Re: PaceEnclosuresAndPix status

On Mon, 24 Jan 2005 20:08:36 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote: -0.7. Turns into a kitchen sink by using it to point to things that are intended to be pre-fetched and presented along with the content I agree. I think we should have chosen another element name. turns out to be

Re: PaceIRI status

At 9:16 AM +0100 1/25/05, Julian Reschke wrote: I saw some concerns (with which I agree) that requiring the presence of an IDN library is problematic. As far as I can tell, it's likely to be ignored by developers of clients that run on somwehat constrained devices. I would like to hear more from

Re: PaceEnclosuresAndPix status

AsbjÃrn wrote: -0.7. Turns into a kitchen sink by using it to point to things that are intended to be pre-fetched and presented along with the content I agree. I think we should have chosen another element name. turns out to be HTML's where just Âeverything goesÂ. I don't like it, but if

Re: PaceFeedLink

On Jan 25, 2005, at 7:39 AM, Anne van Kesteren wrote: Agreed. Then the only comment that remains is: # Also, could an additional requirement be added. Namely that # aggregators use the URI in |rel="self"| to check for the feed next # time? -1 If I got the feed from location X, I may choose to do so

PaceAttributesNamespace refactored

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 namespace, reducing ambiguity. I would expect the reduction of ambiguity is desirable in a spec. This should

Re: PaceAttributesNamespace status

On Tue, 25 Jan 2005 14:30:14 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: > So I'd conclude that the specification is silent on the matter of > attribute prefixing doesn't make things less messy, it's somewhat messy > already; specification just shines a light on that. Indicating digust > doesn

Re: PaceDateUpdated2 status

On Tue, 25 Jan 2005 13:28:36 +1100, Eric Scheid <[EMAIL PROTECTED]> wrote: Did someone do a survey of what date concepts the various blog publishing systems support? Yes: http://intertwingly.net/wiki/pie/BlogToolDateSurvey> -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loa

Re: PaceAttributesNamespace status

On Tue, 25 Jan 2005 10:07:05 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: 2. It's not clear how you'd pepper atom elements with attributes (ie do we spec that you must put your extra attribs in a namespace?). This should be made clearer. What I would suggest (for the spec'ed XML serialization

Re: PaceEntriesAllTheWayDown status

On Mon, 24 Jan 2005 16:17:48 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: If there were no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the line. -Tim I haven't seen it before, but think it's a nice proposal.

Re: PaceExtendingAtom status

On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: Absent some convincing -1s, it probably goes in. -Tim It says nothing about namespaces. Shouldn't it mention that all foreign markup should be namespaced, and that all elements within the Atom namespace that aren't underst

Re: PaceSyntaxGuidelines status

On Mon, 24 Jan 2005 18:08:08 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: You know, I'd never really thought about this one, but now that I have, I wonder why on earth we should be trying to micromanage syntax for people we don't know writing extensions we know nothing about to solve problems w

Re: PaceMustBeWellFormed status

On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim I think we should do something about it, if we don't incorpor

Re: PaceSyntaxGuidelines status

Asbjørn Ulsberg wrote: I came up with the guidelines because I'd like to see Atom, with extensions, look as clean and easilly readable as possible. If Atom becomes a mish-mash of different syntax «standards», it will be horrible to read, parse and generate. Asbjørn, I can sympathize with the

Re: PaceSyntaxGuidelines status

On Tue, 25 Jan 2005 14:37:56 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: Asbjørn, I can sympathize with the goal, but it's not appropriate to include in the spec. It's babysitting. I kind of agree. If the mythical Implementor's Guide were to materialize, it might make a good home for this

Re: PaceEntriesAllTheWayDown status

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

Re: PaceMustBeWellFormed status

--On Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray <[EMAIL PROTECTED]> wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim I'm +1 on this, and feel that it belongs in the spe

Re: PaceMustBeWellFormed status

Walter Underwood wrote: --On Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray <[EMAIL PROTECTED]> wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim I'm +1 on this, and feel

Re: PaceEntriesAllTheWayDown status

On Tue, 25 Jan 2005 20:59:08 +0100, Henry Story <[EMAIL PROTECTED]> wrote: Are we speaking about PaceEntriesAllTheWayDown2 here? I never saw PaceEntriesAllTheWayDown, but PaceEntriesAllTheWayDown2 looks good; so, yes. Because if we are I am still behind it, (though it may need adapting as i

Re: PaceMustBeWellFormed status

Walter Underwood wrote: --On Monday, January 24, 2005 04:17:40 PM -0800 Tim Bray <[EMAIL PROTECTED]> wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim I'm +1 on this, and feel

Re: PaceEnclosuresAndPix status

A suggestion on drafting of the pace: cardinality should be stated. The idea of multiple parallel elements formatted per PaceEnclosuresAndPix was discussed with interest, and the cardinality of RSS 2.0 enclosure elements has been written up and discussed quite a lot, so the cardinality of PaceE

Re: PaceMustBeWellFormed status

--On Tuesday, January 25, 2005 03:39:13 PM -0500 Robert Sayre <[EMAIL PROTECTED]> wrote: I'm very -1 on this, since it makes the definition of the Atom format an HTTP message, rather than an XML document. On top of that, most of the Pace is babysitting. To the Guide with it. Except that there is no

Re: PaceMustBeWellFormed status

Walter Underwood wrote: --On Tuesday, January 25, 2005 03:39:13 PM -0500 Robert Sayre <[EMAIL PROTECTED]> wrote: I'm very -1 on this, since it makes the definition of the Atom format an HTTP message, rather than an XML document. On top of that, most of the Pace is babysitting. To the Guide with i

Re: PaceMustBeWellFormed status

--On Tuesday, January 25, 2005 04:21:29 PM -0500 Robert Sayre <[EMAIL PROTECTED]> wrote: It's required for interop over HTTP. That's off-topic in the format draft, which mentions HTTP once, in passing. So you suggest that we have additional format requirements in the protocol spec? The headers-uebe

Re: PaceMustBeWellFormed status

Walter Underwood wrote: --On Tuesday, January 25, 2005 04:21:29 PM -0500 Robert Sayre <[EMAIL PROTECTED]> wrote: It's required for interop over HTTP. That's off-topic in the format draft, which mentions HTTP once, in passing. So you suggest that we have additional format requirements in the pro

Re: PaceAttributesNamespace refactored

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 nam

Re: PaceAttributesNamespace status

Danny Ayers wrote: On Tue, 25 Jan 2005 14:30:14 +, Bill de hÓra <[EMAIL PROTECTED]> wrote: So I'd conclude that the specification is silent on the matter of attribute prefixing doesn't make things less messy, it's somewhat messy already; specification just shines a light on that. Indicating di

Re: Issues with draft-ietf-atompub-format-04

Anne van Kesteren wrote: * 3.1.1 "type" Attribute I was wondering how I can include MathML in Atom posts or simple SVG fragments. If there are extension mechanisms available, shouldn't 3.1.1 refer to those? You can put it in atom:content. Other core elements are there to provide a *baseline*. *

Re: PaceAttributesNamespace status

> PaceAttributesNamespace I'm -1 on this. It seems to be authorising a RDF users to do a transform on Atom Syntax in order to make it more RDF/XML-like. If RDF users have to transform the content in order to interpret it as RDF/XML (which they do), then they might as well transform it to a dece

Re: PaceSimpleLanguageTagging status

Tuesday, January 25, 2005, 8:00:00 AM, you wrote: > I am strongly opposed to PaceSimpleLanguageTagging. I had two problems with xml:lang: One was implementation difficulty - I think that the level of language support in Atom seems a bit unbalanced. On one hand we can language tag everything a

Re: PaceSimpleLanguageTagging status

Tuesday, January 25, 2005, 5:30:51 AM, you wrote: > At 10:00 05/01/25, Sascha Carlin wrote: >> >>Tim Bray wrote: >>> Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to th

Re: PaceIRI status

At 23:53 05/01/25, Julian Reschke wrote: > >Bjoern Hoehrmann wrote: >> * Julian Reschke wrote: >> >The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which

Re: PaceMustBeWellFormed status

At 07:35 05/01/26, Robert Sayre wrote: > >Walter Underwood wrote: >> 6. Client processing requirements >> >> Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in Section 2.1 of the XML specification . Furthermore, the concept of XM

Re: PaceIRI status

At 01:52 05/01/26, Paul Hoffman wrote: > >At 9:16 AM +0100 1/25/05, Julian Reschke wrote: >>I saw some concerns (with which I agree) that requiring the presence of an IDN library is problematic. As far as I can tell, it's likely to be ignored by developers of clients that run on somwehat constrai

Re: PaceFeedLink

At 00:32 05/01/26, Eric Scheid wrote: > >On 26/1/05 2:16 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: >> Since aggregators already have to support xml:base it would be logical >> to make that a relative URI. > >A relative URI would only be useful if there is in fact an xml:base in >effect. Wi

Re: Questions about -04

(BAt 01:51 05/01/26, Asbj$BS(Bn Ulsberg wrote: (B > (B >On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby <[EMAIL PROTECTED]> (B >wrote: (B > (B >>> 2. Why MUST a feed point to an alternate version. [...] (B >> (B >> I'm -1 on removing this restriction. (B > (B >I thought we came to a sort

Re: PaceSimpleLanguageTagging status

Here is a middle ground. We allow xml:lang, say that it SHOULD be used at the feed and entry level, and that it MAY be used elsewhere, but be aware that the information may be lost when translated to other formats. I'm actually +1 on the original proposal, because it is a good fit to what search en

Re: PaceMustBeWellFormed status

Martin Duerst wrote: >> >> Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in Section 2.1 of the XML specification . Furthermore, the concept of XML well-formedness relies on first determining the character encoding of the XML d

Re: PaceIRI status

On 1/25/05 7:45 PM, "Martin Duerst" <[EMAIL PROTECTED]> wrote: > > At 01:52 05/01/26, Paul Hoffman wrote: >> >> At 9:16 AM +0100 1/25/05, Julian Reschke wrote: >>> I saw some concerns (with which I agree) that requiring the presence of > an IDN library is problematic. As far as I can tell, it'

Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published

At 09:17 05/01/25, Tim Bray wrote: > >If there were no further discussion: It's hard to see how to avoid adopting this now that IRIs are standards-track RFC. -Tim Some good news: The IRI spec is now published as RFC 3987 (Proposed Standard, http://www.ietf.org/rfc/rfc3987.txt). The update of the

Re: PaceMustBeWellFormed status

On 26/1/05 8:58 AM, "Walter Underwood" <[EMAIL PROTECTED]> wrote: > An external transport protocol (e.g. HTTP with text/xml content-type) > may force the document to be decoded as US-ASCII. In that case ... +1 e.

Re: Issues with draft-ietf-atompub-format-04

Eric Scheid wrote: On 26/1/05 11:03 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: It is a bit vague that this TYPE attribute differs from the one in section 3.1.1. Where this one MUST have a MIME type as value the other MUST NOT. This is incorrect. huh? link constructs MAY have a typ

Re: PaceFeedLink

On 26/1/05 4:44 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> Agreed. Then the only comment that remains is: >> >> # Also, could an additional requirement be added. Namely that >> # aggregators use the URI in |rel="self"| to check for the feed next >> # time? > > -1 > > If I got the feed from l

Re: PaceFeedLink

On 26/1/05 11:50 AM, "Martin Duerst" <[EMAIL PROTECTED]> wrote: >> A relative URI would only be useful if there is in fact an xml:base in >> effect. With no xml:base then the relative reference would be useless. > > That's pretty obvious, and applies to all other links. If we want to > point tha

Re: PaceEnclosuresAndPix status

On 26/1/05 3:59 AM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> -0.7. Turns into a kitchen sink by using it to point to things >> that are intended to be pre-fetched and presented along with the content > > I agree. I think we should have chosen another element name. turns > out to be HTM

Re: Issues with draft-ietf-atompub-format-04

On 26/1/05 2:49 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> [3.1.1 says TYPE is one thing] >> [3.5.2 says TYPE is the opposite] > Ah, you're right. Still don't see how it's vague, though. It's only clear what's going on when the reader juxtaposes the two sections, and realises that the con

Re: Issues with draft-ietf-atompub-format-04

Eric Scheid wrote: Ah, you're right. Still don't see how it's vague, though. It's only clear what's going on when the reader juxtaposes the two sections, and realises that the concept named 'type' in section [3.1.1] is not the same concept named 'type' in section [3.5.2]. Without that juxtapos

Re: PaceMustBeWellFormed status

* Robert Sayre wrote: >I'm very -1 on this, since it makes the definition of the Atom format an >HTTP message, rather than an XML document. It seems common practise to include requirements for implementations of a format into the specification of the format. Why should these be kept separate? In

Re: content for text/ or +xml SHOULD be local? (was: Re: Hash for Links)

On Tue, 11 Jan 2005 16:46:35 +0900, Martin Duerst <[EMAIL PROTECTED]> wrote: "If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided." When I read this, I was somewhat surprised to find a SHOULD. A should

Re: PaceMustBeWellFormed status

* Tim Bray wrote: >On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote: >> It's good work but it belongs in a primer or best practices document. > >+1. I like it, I'd like to use it somewhere, but I don't think it >belongs in the core spec. -Tim I am afraid, if requirements ala "clients MUST stop p

Re: PaceMustBeWellFormed status

* Tim Bray wrote: >If there were no further discussion: The WG completely failed to >converge to consensus on these issues last time around. Consensus can >still be found here. -Tim I would suggests we contact implementers and ask them whether they will conform to these requirements or not. If

Re: Revisiting feed discovery

On Fri, 21 Jan 2005 17:35:05 +1100, Eric Scheid <[EMAIL PROTECTED]> wrote: How is a resource which shows the last 15 entries as of today an "alternative" representation of an entry which was published six months ago and has long slipped out of the sliding window? It isn't, and that's not what

Re: Revisiting feed discovery

On 26/1/05 5:02 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> How is a resource which shows the last 15 entries as of today an >> "alternative" representation of an entry which was published six months >> ago and has long slipped out of the sliding window? > > It isn't, and that's not what

AtomAsRDF step 2

Thanks David. I take it that you would be +1 if you thought the AtomAsRDF project were feasible. Thanks a lot for the list of problems you think this entails. These need to be considered one by one. On 26 Jan 2005, at 02:20, David Powell wrote: PaceAttributesNamespace I'm -1 on this. It seems to