Re: xsd:dateTime vs. RFC 3339

Norman Walsh wrote: / Julian Reschke <[EMAIL PROTECTED]> was heard to say: | -> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we | may have to profile one of them. In which case I'd prefer to stick | with RFC3339. Perhaps a compromise? Date Construct values

Re: xsd:dateTime vs. RFC 3339

Walter Underwood wrote: --On February 4, 2005 11:18:17 AM -0500 Norman Walsh <[EMAIL PROTECTED]> wrote: I know we're writing an IETF document, but I think there's going to be a lot of off-the-shelf XML software that understands xsd:dateTimes and I think it would be a lot better if we defined Date C

Re: xsd:dateTime vs. RFC 3339

Julian Reschke wrote: ... 2. RFC 3339 allows the replacement of the 'T' with a space which xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC 3339 isn't actually a "profile of ISO 8601" as it claims]. As far as I can tell, ISO 8601 allows this. An

Re: xsd:dateTime vs. RFC 3339

Norman Walsh wrote: The 05 draft of the Atom format says: 3.3 Date Constructs A Date construct is an element whose content MUST conform to the date-time BNF rule in [RFC3339]. I'm actually using xsd:dateTime in the RELAX NG grammar and I went off to look at RFC 3339 thinking I mi

Re: xsd:dateTime vs. RFC 3339

Robert Sayre wrote: Norman Walsh wrote: The 05 draft of the Atom format says: I know we're writing an IETF document, but I think there's going to be a lot of off-the-shelf XML software that understands xsd:dateTimes and I think it would be a lot better if we defined Date Constructs in terms of W3C

Re: PaceMustBeWellFormed

Bill de hÓra wrote: If, - 6.2 was dropped and probably - the first sentence of the Pace was dropped, - the rest of the 1st para was dropped down into 6.1 - there was some weasel wording about RFC3023 compliance how would you feel about the rest of it? ... I think the main issue here is first we

Re: tagline -> subtitle

Graham wrote: Any chance of renaming atom:tagline to atom:subtitle? The two sample feeds posted today have the taglines "ongoing fragmented essay by Tim Bray" and "WebDAV related news". Aren't taglines meant to be funny or catchy or clever? The relevant definitions from dictionary.com are: tag

Re: Trial format-05 atom feed

Tim Bray wrote: On Feb 2, 2005, at 4:26 AM, Julian Reschke wrote: Same here (<http://greenbytes.de/tech/webdav/webdav.atom>). The empty summaries seem to me to be legal but surprising. Hmm... the "summary" text is in the titles. Kind of surprising but I guess it works. You

Re: Trial format-05 atom feed

Sam Ruby wrote: Julian Reschke wrote: Tim Bray wrote: Just to see if it uncovered any problems, I twiddled the ongoing software to generate a format-05 atom feed. It didn't uncover any problems that I could see. Norm's RNC schema was very valuable in debugging, not that there were

Re: Trial format-05 atom feed

Tim Bray wrote: Just to see if it uncovered any problems, I twiddled the ongoing software to generate a format-05 atom feed. It didn't uncover any problems that I could see. Norm's RNC schema was very valuable in debugging, not that there were many bugs. Check it out at http://www.tbray.org/

Re: Format spec vs Protocol spec

Robert Sayre wrote: Tim Bray wrote: On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). I suggest this can and should be removed. Agree

Format spec vs Protocol spec

Hi, (I raised this when reviewing draft 05 already, but I think this topic deserves it's own thread) Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). As far as I understand the IETF pub

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Tim Bray wrote: On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote: 05-C05, 4.15.3 processing model "If the value of "type" begins with "text/" the content of atom:content MUST NOT contain child elements." See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Robert Sayre wrote: Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of "alternate".' Can't we just get rid of the defaulting? That would make the spec simpler with little additional verbosity in the instance documents. In this case, my pref

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Robert Sayre wrote: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of "alternate".' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of "alternate".' Can't we just get rid of the defaulting? That wo

Re: atom:info [was Re: Comments on format-05]

Mark Nottingham wrote: And, if you use XSLT, it's also possible to do it all in-stylesheet, with or without links. Safari (and probably other things) don't do XSLT. Fair enough. Safari is said to get a (libxml-based) XSLT engine in the next major upgrade. Best regards, Julian -- bytes GmbH --

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Sam Ruby wrote: Julian Reschke wrote: http://www.w3.org/1999/xhtml";> Less: < (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: http:/

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Thanks for the feedback, Robert... Robert Sayre wrote: - "rel" attribute is missing The rel attribute is optional and the relation is considered to be "alternate" in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute

Re: Comments on format-05

Robert Sayre wrote: Tim Bray wrote: On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote: We should either explicitly allow application/xml in section 2, or remove this element. I'm not sure which I prefer. atom:info is useful during transformations. Tossing atom:info will result in interoperabilit

Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Tim Bray wrote: On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote: The issues were collected after reading the spec top-to-bottom, and trying to produce an Atom-05 feed from an existing RSS-1.0 feed through XSLT. Most of them are editorial. Good stuff, Julian. Thanks. "If the value of

Re: Comments on format-05

Mark Nottingham wrote: > ... +1 There may be good reasons for atom:host and atom:info to be there, but they aren't really obvious by reading the spec alone. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt

Hi, first I'd like to thank the editors for the good work. The issues were collected after reading the spec top-to-bottom, and trying to produce an Atom-05 feed from an existing RSS-1.0 feed through XSLT. Most of them are editorial. Best regards, Julian -- snip -- 05-C01, 1.2 Example

Re: URI canonicalization

Robert Sayre wrote: Um, the spec doesn't say you can. If the comparision is done with URI.equals(), it will be positive. If it is done with String.equals(), it will be negative. That text is a refelection of reality.

Re: PaceXhtmlNamespaceDiv posted

Tim Bray wrote: On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote: That's an implementation issue that shouldn't affect the format. Without any comment on the issue Julian was addressing, the above is outrageous. Implementation issues are extremely material in discussion of

Re: URI canonicalization

Robert Sayre wrote: Tim Bray wrote: On Jan 30, 2005, at 9:50 AM, Graham wrote: 2) An intermediary automatically c14nizes all URIs it processes. If URIs come pre-c14nized from the publisher, this won't do any damage. This is valid, but the problem is that these intermediaries are currently imagin

Re: PaceXhtmlNamespaceDiv posted

Eric Scheid wrote: On 31/1/05 4:43 AM, "Julian Reschke" <[EMAIL PROTECTED]> wrote: "The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element." ...so making it explicit in the on-the-wire format seems to be completel

Re: PaceXhtmlNamespaceDiv posted

Graham wrote: On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote: I've reopened it minus the namespace restriction. I realize that Henri is violently opposed to it, but his objection seem to reduce down to "cruft", and he seems to be in the minority. I see there to be a good chance that rough consensu

Re: PaceXhtmlNamespaceDiv posted

Sam Ruby wrote: ... I've reopened it minus the namespace restriction. I realize that Henri is violently opposed to it, but his objection seem to reduce down to "cruft", and he seems to be in the minority. I see there to be a good chance that rough consensus can be found on this pace. ... For t

Re: PaceXhtmlNamespaceDiv posted

Sam Ruby wrote: I also don't like the restriction on where namespace declarations must be placed, but overall, I believe that the pace is a good idea. Consumers don't want full web pages (complete with html head and titles) as summaries, they want something that they can *insert* into a web page.

Re: Mandatory method of specifying XHTML namespace?

Tim Bray wrote: He's got a point. It's a common (and many people say, good) idiom to declare all your namespaces on your root. I think all we can/should really say is that when type="XHTML", it is the responsibility of the feed generator to declare the XHTML namespace, because Atom won't do it

Re: PaceIRI status

Martin Duerst wrote: ... Bjoern was making a vaild, but fine, point: Because we decided to refer to RFC2396bis, rather than to RFC2396, we already have bought into the fact that RFC2396bis allows percent-encoded domain names, and thus essentially requires IDN support. (apart from the basic fact tha

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: 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 inst

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#se

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

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

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

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: Editorial suggestions for Atom -04

Norman Walsh wrote: ... |Any element in an Atom Document MAY have an xml:base attribute. XML |Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any |relative reference [RFC2396bis] present in an Atom Document. This s/relative reference/relative URI reference/ "Relative ref

<    1   2