Re: I-D ACTION:draft-ietf-atompub-protocol-13.txt
[EMAIL PROTECTED] schrieb: A New Internet-Draft is available from the on-line Internet-Drafts directories. ... Hmmm, didn't we have agreement to change 'application/atomserv+xml' to 'application/atomsvc+xml'? Best regards, Julian
Re: AD Evaluation of draft-ietf-atompub-protocol-11
James M Snell schrieb: Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. ... Again: WebDAV doesn't redefine PUT, so the situation is exactly the same. (Unless you were referring to PROPFIND/PROPPATCH). Best regards, Julian
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Joe Gregorio schrieb: ... This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html WebDAV doesn't make any promises about what servers do upon PUT. It just relies on RFC2616. Best regards, Julian
Re: [rss-public] Autodiscovery IPR and Process Concerns
James M Snell schrieb: ... Now, to the WG as a whole: I really don't have any agenda for the autodiscovery stuff other than to help foster it along. If y'all think there is a need for a I-D defining autodiscovery for Atom and APP, I've got a few spare cycles to help with the editing. If y'all think the HTML5 stuff is sufficient, that's fine with me too. If y'all want to go some other direction with it, whatever. ... My 2 cents: it's nice that the HTML5 guys are looking at this, but they are so far away from being able to deliver something that I really would prefer that this is documented now. So, yes, I think you're on the right track. Best regards, Julian
Re: Response to appeal by Robert Sayre dated 2006-08-29
Well. Could the IESG then please answer the following simple question...? If HTTP/1.1 (as defined in RFC2616) would be submitted today for publication as Proposed Standard, would it be accepted? If no, shouldn't the IESG revoke the current status of Draft Standard, and declare it as historic (as per RFC2026, Section 6.2)? (that is, the documented standards process clearly isn't the *current* standards process, thus it seems funny to me that the IESG claims BCPs to be the last word when in fact one of the most successful protocols on this planet doesn't comply to them). Best regards, Julian
Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07
Mark Nottingham schrieb: I've only had positive comments about -07 so far, so I've recommended it for publication as a Proposed Standard to the IESG. As part of that process, I'm issuing an informal, pseudo-WG Last Call on the document to capture any remaining feedback. In particular, * What do people think about putting this document on the Standards Track? * Do you have an implementation available, in progress, planned, etc.? http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/ Please provide feedback by October 18th. Cheers, -- Mark Nottingham http://www.mnot.net/ Looks all good to me, except for the nits below: - you want to update the xml-names reference to http://www.w3.org/TR/2006/REC-xml-names-20060816/ - you may want to change the xml2rfc list style in Section 5 to empty Best regards, Julian
Re: Atom Syndication Format To Draft Standard?
Paul Hoffman schrieb: Dang, where'd that rule come from? Probably RFC 2026, but if not there, it is certainly in the folklore of How Things Are Done. ... I thought this is possible if interop is demonstrated... ... Best regards, Julian
Re: Atom Syndication Format To Draft Standard?
Paul Hoffman schrieb: At 3:01 AM -0400 10/2/06, Robert Sayre wrote: I think we should move the format to Draft Standard by clearing up any errata and adding two attributes: 'dir' and 'unicode-bidi', as defined in XHTML. We can't both add features and move to Draft Standard at the same time. If we add features, we would recycle at Proposed Standard. Errata that are truly that and not technical changes can be made when moving to Draft Standard. ... Independantly of that, what do we do with all the normative references to proposed standards...: Normative References: REC-html401-19991224: [REC] ok RFC4288: [BEST CURRENT PRACTICE] (- BCP0013) RFC2119: [BEST CURRENT PRACTICE] (- BCP0014) RFC2822: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC2854: [INFORMATIONAL] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3023: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3066: [BEST CURRENT PRACTICE] obsoleted by RFC4646 RFC4647 RFC3339: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3548: [INFORMATIONAL] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3986: [STANDARD] (- STD0066) RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! REC-xml-20040204: [REC] ok REC-xml-c14n-20010315: [REC] ok REC-xml-exc-c14n-20020718: [REC] ok REC-xml-infoset-20040204: [REC] ok REC-xml-names-19990114: [REC] ok REC-xmlbase-20010627: [REC] ok REC-xmldsig-core-20020212: [REC] ok REC-xmlenc-core-20021210: [REC] ok REC-xhtml-modularization-20010410: document unknown Informative References: ISO.8601.1988: not checked RELAX-NG: not checked RFC2434: [BEST CURRENT PRACTICE] (- BCP0026) NOTE-datetime-19980827: document unknown REC-xmlschema-2-20041028: [REC] ok ? Best regards, Julian
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
Robert Sayre schrieb: ... Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? ... Although I share Robert's concerns about how this spec became a Proposed Standard, I really have trouble to see the issue here. As a matter of fact, I'm using a purl.org URL in one of my (non-Atom related) drafts as well. What we're talking about here is not change control over the namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. My (and I assume also James') assumption is that once the specification is out, the purl.org HTTP URL will be reconfigured so that it redirects to a URL identifying the actual RFC (preferably to readable HTML :-). All of this is only necessary because the IETF insists in not minting HTTP URLs themselves. I think the argument is that they can become unstable. Of course that depends on the organization minting them and maintaining the servers, not the actual type of URI... (note that even the BCP for usage of XML in IETF specs -- RFC3470 -- mentions that it would be good if the IETF would allow URLs from www.ietf.org for this purpose). Best regards, Julian
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
Sylvain Hellegouarch schrieb: ... Just a thought like that but wouldn't it make sense for RFC 4287 to have specified that every standardised extension should follow the same namespace as RFC 4287? For instance RFC 4287 uses http://www.w3.org/2005/Atom Extensions should then be something like: http://www.w3.org/2005/Atom-FTE It's just a rough idea. ... Well, that makes standardizing extensions much harder (you need the W3C assistance in getting a namespace URI) with no gain (at least, as far as I can tell). It's a *feature* that it is so easy to define a globally unique XML namespace name. Best regards, Julian
Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.]
Thomas Broyer schrieb: If I read RFC2616 correctly, nothing prevents the latest entries only and full representations (or any representation of the same resource) to share the same entity-tag, i.e. nothing prevents a server to assign an entity-tag to a resource rather than its representations. Maybe servers should use a weak etag in this case? But RFC2616 says in section 13.3.3 that Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request. ... I think this is a misunderstanding of how HTTP/1.1 is supposed to work. If a server returns the same ETag for different entities returned for the same URL, this will cause breakage of caches. You may want to re-read Section 13.6 of RFC2616 (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.6). Best regards, Julian
Re: when should two entries have the same id?
Elliotte Harold schrieb: James M Snell wrote: That's not quite accurate. Two entries with the same atom:id may appear within the same atom:feed only if they have different atom:updated elements. The spec is silent on whether or not two entries existing in *separate documents* may have identical atom:id and atom:updated values. They're ids, not guids. Certainly I would expect that there'll be some accidental conflicts. For instance one site might number its posts post1, post2, post3,...; and a different, unrelated site might do the same. Sorry? That would be a bug. They *are* supposed to be globally unique. See: http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6. Best regards, Julian
Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))
I'm with Robert here. To clarify what happened with the WebDAV specs he mentioned...: - WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda, and currently is implemented only by two vendors. Thus, experimental seems to be absolutely the right category. - WebDAV Redirect References (RFC4437) was on the working group's agenda, but in the end too few implementors seemed to be interested (again: two). Thus experimental wasn't what I would have hoped to achieve, but at least this kind of publication preserves the effort that was invested, and it also documents running code in some implementations. Best regards, Julian
Re: Datatype for IRIs in RELAX NG
Martin Duerst wrote: At 02:08 06/03/20, Elliotte Harold wrote: I would recommend against using xsd:anyURI for IRIs. A URI is much more restrictive than an IRI, and one of the easiest things for a schema validator to check about an xsd:anyURI is that it only contains URI-legal ASCII characters. This is indeed one of the easiest things, but it would be TOTALLY wrong. http://www.w3.org/TR/xmlschema-2/datatypes.html#anyURI says, among else: The mapping from anyURI values to URIs is as defined by the URI reference escaping procedure defined in Section 5.4 Locator Attribute of [XML Linking Language] (see also Section 8 Character Encoding in URI References of [Character Model]). This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 2396], as amended by [RFC 2732], where appropriate to identify resources. If there is confusion in other venues about this issue, please help to make sure it gets fixed. Well, maybe it's time that *some* specification adds new datatypes that do *exactly* what RFC3986 and RFC3987 ask for :-) Best regards, Julian
Re: HTML/XML version of RFC4287
Hi, in the meantime Mark N. sent me the XML version of the submitted draft (thanks!), which I have updated with the AUTH48 changes in RFC4287 (I also changed it to be self-contained). XML and HTML versions are now available from http://greenbytes.de/tech/webdav/#rfc4287. Note that the XML version makes use of some extensions implemented only in rfc2629.xslt, thus you'll need the clean-for-DTD.xslt transformation to transform it to something xml2rfc will accept (see http://greenbytes.de/tech/webdav/rfc2629xslt.zip). Best regards, Julian
[Fwd: WGLC of draft-ietf-webdav-rfc2518bis-14.txt]
Hi, the IETF WebDAV working group finally has produced a draft for the revision of RFC2518 that we feel can be last-called in the working group -- see Cullen's announcement below. At this point it would be great to get feedback from people who currently do not follow the WebDAV working group's mailing list, but who do have an interest in HTTP, authoring, and related areas. The last-called draft is at http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-14.txt. Diffs between individual drafts can be found at http://tools.ietf.org/wg/webdav/draft-ietf-webdav-rfc2518bis/. Changes to RFC2518 are (hopefully completely) summarized in Appendix E (see http://tools.ietf.org/html/draft-ietf-webdav-rfc2518bis-14.txt#page-135). Discussion takes place on the WebDAV mailing list (mailto:w3c-dist-auth@w3.org), which may be joined by sending a message with subject subscribe to mailto:[EMAIL PROTECTED]. Discussions of the WebDAV working group are archived at http://lists.w3.org/Archives/Public/w3c-dist-auth/. There's also a bug tracker at http://ietf.cse.ucsc.edu:8080/bugzilla/, which may be useful to find out whether a particular issue already has been raised. For new issues, please report them to the mailing list first, though. (I am sending this announcement to various mailing lists, so you may get multiple copies. Apologies.) Best regards, Julian Original Message Date: Wed, 22 Feb 2006 07:42:18 -0800 From: Cullen Jennings [EMAIL PROTECTED] To: WebDav w3c-dist-auth@w3.org I am absolutely thrilled to be able to Working Group Last Call (WGLC) draft-ietf-webdav-rfc2518bis. The WGLC will end on March 15, 2006. I am aware of one complex open issue with this version of the draft. The use of ETAGs in the response to a HTTP PUT is not exactly clear in the HTTP spec and this has implications for WebDAV. Some folks are working on a draft to clarify this in HTTP. I'm sure this issue will be discussed during the Last Call. On minor issues, Julian will be proposing new text for bug 143. The if header section needs particularly careful review. I would like to ask everyone to read this. We really need to get some fresh eyes reading this document. Did we get it right? Is there enough detail that you can implement it? Does this clarify previous interoperable problems? Thank you, Cullen I'd like to take this moment to thank the several contributors that put in a ton of work to make this happen and to all the folks on the mailing list that put up with the roughly two thousand email posts from bugzilla. I really hope the volume of these will be reducing.
HTML/XML version of RFC4287
Hi, is anybody aware of ongoing activities to produce XML/HTML versions of RFC4287 based on the xml2rfc (rfc2629) XML format? I'm fully aware that there currently probably is no XML version of the spec that matches RFC4287, as the AUTH48 changes done by the RFC Editor have been applied to a derived NROFF version. But clearly there has been an XML version of the latest draft (draft-ietf-atompub-format-11), so it shouldn't be impossible to update that one accordingly. And yes, I'm volunteering to do that work. Best regards, Julian
Re: FYI: Google Reader and Atom 1.0
James M Snell wrote: FYI: Thanks to Robert Sayre for pointing it out, but when y'all get a chance, take a look at the internals of the new Google Reader app (http://reader.google.com). It's using AJAX and Atom 1.0 feeds to serve up the data into the browser interface. The interface itself leaves a lot to be desired, but the model they're using is significant. Well worth a look. Hm. As far as I can tell, it doesn't process Atom content of type XHTML, for instance (http://greenbytes.de/tech/webdav/webdav.atom). Best regards, Julian
[feedvalidator] Two entries with the same value for atom:updated
In http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fgreenbytes.de%2Ftech%2Fwebdav%2Fwebdav-ietf.atom, why is the validator complaining about atom:updated elements to be the same...? After all, both entries have different atom:id elements... Confused, Julian
Re: [feedvalidator] Two entries with the same value for atom:updated
James Holderness wrote: If you read the help on that error message you'll see it's quoting directly from section 3.3 of the Atom spec: Date values SHOULD be as accurate as possible. For example, it would be generally inappropriate for a publishing system to apply the same timestamp to several entries which were published during the course of a single day. With a date format that is perfectly capable of representing the time with millisecond precision, the chances that two entries in a feed have the exact same time are fairly low, unless you're not producing very accurate times (which certainly seems to be the case with that feed). Well, yes. The information source doesn't provide timestamps, just dates. ... Best regards, Julian
Re: spec bug: can we fix for draft-11?
Dave Pawson wrote: On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote: I'm getting increasingly grumpy and just fail is looking better and better. So for now, I'm -1 on an weakening or removing The element's content MUST be an IRI or analogous text in any other section. I'll stop shouting if I'm in a small minority here. It's clean, except I'd like an informative statement for people failing and wondering why. And something in the schema that lets people know why, since we can validate against the schema and *pass*? Now that could be confusing. regards DaveP +1 on both (not changing the semantics, but possibly adding a warning that whitespace *really* is significant here). regards, Julian
Re: spec bug: can we fix for draft-11?
Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). +1 A potential enhancement would be to explicitly state that whitespace *isÜ significant here (and of course to make the feedvalidator check it). Best regards, Julian
Re: spec bug: can we fix for draft-11?
Bill de hÓra wrote: Julian Reschke wrote: Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). +1 A potential enhancement would be to explicitly state that whitespace *isÜ significant here (and of course to make the feedvalidator check it). That still leaves things unsaid - significant in what way? What does make the feedvalidator check it entail? And assuming we did this enhancement how does whitespace square with our MUST be an IRI. If you put whitespace inside, it's part of the to-be-IRI. As an IRI can not contain whitespace, it's an invalid IRI. Somebody please convince me the spec is adequate here; I'm not seeing it. I'm feeling an urge to go through all the elements for any other machine readable tokens living inside element content and filing bugs against the lot of them. Then I'll do the same with APP constructs like 'draft'. Seems that the spec may need to define once what it means to say that the content of an element must be something specific, such as an IRI. Best regards, Julian
Re: spec bug: can we fix for draft-11?
James Cerra wrote: Ian Davis wrote: Graham wrote: That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). Leading and trailing whitespace should be stripped from the content of an atom:id element. The two examples that Bill gave WILL happen in the wild and Atom consumers will just deal with it by stripping the whitespace anyway despite what the spec says now. I think this should be endorsed in the spec for interoperability. +1. But Sam Ruby's first draft at [1] demostrated more than just atom:id. (He changed it now so that the examples don't have white space showing! lol!) They also included things like: id http://example.com/ /id updated 2003-12-13T18:30:02Z /updated Neither of those are strictly legal, since white space is illegal in both IRI and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer used. Why would they be legal with the RNG grammar ... Best regards, Julian
Re: spec bug: can we fix for draft-11?
Sam Ruby wrote:
...
Why would they be legal with the RNG grammar
From http://www.w3.org/TR/xmlschema-2/#dt-whiteSpace:
For all ·atomic· datatypes other than string (and types ·derived· by
·restriction· from it) the value of whiteSpace is collapse and
cannot be changed by a schema author; for string the value of
whiteSpace is preserve; for any type ·derived· by ·restriction· from
string the value of whiteSpace can be any of the three legal values.
Thanks for the XML Schema lesson. I wasn't aware of that.
That being said, the RNC grammar for atom contains:
atomId = element atom:id {
atomCommonAttributes,
(atomUri)
}
# Unconstrained; it's not entirely clear how IRI fit into
# xsd:anyURI so let's not try to constrain it here
atomUri = text
Well, *now* it seems that we really need to clarify.
Best regards, Julian
Re: Atom error pages
Thomas Broyer wrote: ... * when using the Atom Publishing Protocol's POST or PUT, it might be worth defining an error document type to tell the client why its document has been refused (e.g. POSTing an Atom Entry with a base64-encoded MSWord content and the server only accepts the three basic content types; or an Atom Entry with more than one category to a server supporting only one category per entry; or using an extension control information not supported by the server: it should be able to tell the client which one has been refused; etc.) You may want to check... http://greenbytes.de/tech/webdav/rfc3253.html#method.preconditions.and.postconditions Best regards, Julian
Re: Atom error pages
A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-07-26 01:00]: part of the issue was what happens if the http response is 200 but the payload is trying to communicate that an error occurred. Nothing happens. 200 means no error occured. Returning 200 when an error did occur is broken and should be fixed on the producer end. Period. I don’t want to see any compromise on this, ever. ... 1 Best regards, Julian
Re: Evangelism, etc.
Danny Ayers wrote: If I could distract folks from the champagne and crudities for a moment: First - I just received a rewrite of the spec draft in nicely-styled XHTML 1.0, from someone (who wishes to remain anonymous) who refers to the IETF docs as so 1989 - http://dannyayers.com/atom/draft-ietf-atompub-format-10.xhtml ... Just run the XML version of the spec through rfc2629toXhtml.xslt (http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629toXHTML.xslt). Best regards, Julian
Re: some small comments on 08
Thomas Broyer wrote: It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in Consensus call on last raft of issues [1] ... For the record: I am +1 on http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv. Best regards, Julian
Re: multiple atom:author elements?
Eric Scheid wrote: On 20/5/05 2:10 PM, Antone Roundy [EMAIL PROTECTED] wrote: If we do allow multiple authors, we might want to put a warning in that consuming applications MAY ignore some of them if more than one is supplied. As long as we do that, and perhaps even if not, I'd be in favor of allowing more than one. I'm happy with that - the market will sort out what is an acceptable level of support. I really don't want to see this in an Atom feed: authornameRaggett, D, Hors, A, and I Jacobs/name/author (perfectly acceptable for display, but not for data) +1 As a general rule: trying to forbid reasonable things usually causes producers to look for workarounds that seem to work in most clients. This is a very nice example where insisting on a single entry will probably do more harm than allowing multiple entries. Julian
Re: extensions -- Atom NS and unprefixed attributes
Tim Bray wrote: On May 16, 2005, at 10:44 AM, Robert Sayre wrote: I am not looking for a repeat of that discussion. Atom 1.0 Processors cannot distinguish between markup added later on by the IETF and markup added by a third party, so the processing rules must remain as they are. That doesn't mean we should allow anyone and everyone to add elements and attributes to the Atom namespace. My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It's like clauses in constitutions saying this clause can't be amended, well yes it can and will be if enough people want it to. I guess staking the claim is not actively harmful. FWIW I don't recall ever seeing such language in any other specs, but maybe I just wasn't looking. -Tim http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.5: Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC. This hasn't been always succesfull, but at least the Working Group can point people to that section in case they try (and they try quite often :-). Best regards, Julian
Re: Fetch Me A Rock
Paul Hoffman wrote: Thus spake RFC 2119: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ...and I think that what we need to do is to define what these full implications are. ... Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by interoperate. Must a receiving implementation handle missing elements? I don't think as long as we say sender SHOULD include the element. ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceOptionalSummary
Sam Ruby wrote: ... The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. ... Not true. Quoting RFC2616: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. ... Best regards, Julian
Re: PaceNoAlternateForFeed
Bill de hÓra wrote:
...
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
...
link rel=no-alternate /
...
Is this meant to be a serious proposal? Why can't ve just leave a
protocol element out if we don't have information for it???
Best regards,
Julian
Re: PaceNoAlternateForFeed
Bill de hÓra wrote: ... Currently you MUST provide an alternate feed link. People are saying they don't always have one to provide, which encourages garbage out. That satisfying a spec constraint for its own sake. This addition allows someone to say there is no alternate for this link. It's less ambiguous than not providing an alternate and more useful than providing junk links. Not present is not the same as not the case. ... How is it less ambiguous if the spec states that the absence of the link means that there is no alternate information? Best regards, Julian
Re: PaceOptionalFeedLink
Graham wrote: On 6 May 2005, at 3:50 am, Sam Ruby wrote: FYI: we have an instance proof of this requiring an existing tool to do additional work: http://www.imc.org/atom-syntax/mail-archive/msg13983.html Tools will have to be updated to work with Atom? Scandalous. +1 to the Pace +1 as well. That something which has been developed against a previous draft will not work with a change in the format seems to be quite natural. On the other hand, we also heard of feeds that need to make up links (which doesn't seem very useful to me). Best regards, Julian
Re: Atom feed refresh rates
Brett Lindsley wrote: Andy, I recall bringing up the same issue with respect to portable devices. My angle was that firing up the transmitter, making a network connection and connecting to the server is still an expensive operation in time and power (for a portable device) - even if the server returns nothing . There is no reason to check feeds that are not being updated, but then, there currently is no way to know this. I recall there was a proposal on cache control. That seemed like a good direction, but I don't recall it being discussed. As you indicated, if the feed had some element that indicated it won't be updated (for example) for another day (e.g. a daily news summary), then the end client would need to only check once a day. Brett Lindsley, Motorola Labs Isn't this what the HTTP Expires header is for (http://greenbytes.de/tech/webdav/rfc2616.html#header.expires)? Best regards, Julian
Re: Atom feed refresh rates
Andy Henderson wrote: Isn't this what the HTTP Expires header is for (http://greenbytes.de/tech/webdav/rfc2616.html#header.expires)? I don't think this helps a lot with my original issue because in many cases a feed's updater will either not know when they will next update the feed, or will be updating the feed frequently throughout the day. If they don't know that, how can the previous response you got help you in determining when to poll next? Best regards, Julian
Re: Autodiscovery
Antone Roundy wrote: On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: Again, my friend's blog feed is not an Atom version of /my/ web page; linking to it as alternate would be wrong. To me, this raises a red flag, suggesting that using an autodiscovery link from your web page to your friend's feed is not what autodiscovery is intended for. +1 Julian
Re: Autodiscovery
Tim Bray wrote: Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG draft, and has done so, see: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml Although Mark's not subscribed, I've agreed to relay any changes that have WG consensus back to him for update; although if they're minor, I guess one of us could just rejigger the XML ourselves. I scanned them and nothing objectionable leapt out at me, but please, could a few more people also have a look? Assuming no errors, or rather that any errors we turn up are fixed, are there any objections to us submitting this I-D as a product of the Atompub WG? -Tim One thing that immediately comes to mind that the references need to be checked, for instance for URI (not RFC2396 anymore) and for XML 1.0 (now at 3rd edition). Best regards, Julian
Re: PaceXhtmlDivSuggestedOnly
For the record...: +1 on not requiring wrapper elements +1 on properly distinguishing between block-level and in-line +1 on using the same recommendations for type=html as well Best regards, Julian
Re: atom:content
Robert Sayre wrote: Julian Reschke wrote: Update -06: I'm still confused by the text. For instance: - is it intentional that 4.1.3.3 says ``If the value of type ends with +xml or /xml'', while 4.1.3.2 used ``If the value of type begins with text/ or ends with +xml''? Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what you find confusing? Actually, this is what I didn't notice. My fault. - also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. point 4, make statements about situations where it comes with @src attribute? I don't know. We should be able to strike them, right? Yes. Either it's a SHOULD level requirement that the content is in-line (in which case we shouldn't say anything about the other case), or IMHO it's not a SHOULD after all. Maybe it's not a SHOULD requirement after all? In particular, that's a should against text/plain and text/html in @src. Hm, I didn't get that. Right now it says (http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.2): 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. Are you saying that the requirements are different for (i) text/ and (ii) for /...+xml? Best regards, Julian
HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Quoting from Andrew Newton's questions relayed by Scott: http://www.imc.org/atom-syntax/mail-archive/msg14048.html From: Andrew Newton [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 6:25 PM To: Scott Hollenbeck Cc: [EMAIL PROTECTED] Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for IETF last call ... 2) Section 4.1.3.3 Item 2 The text: for example, br as lt;br. Is this right? Should it be: for example, br as lt;brgt;. We don't need to escape the in text content, as far as I can tell. Are you suggesting to escape it anyway for consistency/readability? Also, should the must in The HTML markup must be escaped be a MUST? I think so. Should rule 2 have the same note regarding the DIV element as rule 3? What happens if the type is html and the content is all within lt;divgt; lt;/divgt; ? Good question, and an expected one. Lack of consistency here was the reason I made the same suggestion (to either do it for both types, or not to do for it XHTML). ... I'd like to remind us of another related issue raised a few days ago (http://www.imc.org/atom-syntax/mail-archive/msg14045.html). XHTML content is currently restricted to XHTML Basic (see http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3, http://www.w3.org/TR/xhtml-basic/). As far as I can tell, this means *no styling*: - http://www.w3.org/TR/xhtml-basic/#s1.3.1: style attribute not supported (but class is), but - as we require content to be legal within xhtml:div, there's no way to specify CSS information. Although I think it is probably a very good idea to stick with basic markup inside the feed, this seems to introduce an unfortunate disparity between HTML and XHTML, which will result in - people ignoring the XHTML Basic restriction, or, even worse, - people using HTML instead of XHTML to workaround this distinction. I'd propose to go back to XHTML 1.0 Strict instead. Best regards, Julian
strange Live Bookmark display of HTML version of draft in Firefox
Hi, Firefox ironically displays a Live Bookmark icon for http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html :-) This is caused by LINK tags such as link rel=Chapter title=2 Atom Documents href=#rfc.section.2 ...whenever a title contains the string Atom, it is mis-detected as a feed link. Guess we'll need to finish the feed discovery description and send it over to the Mozilla developers... Best regards, Julian
updated issues list for draft 07
Hi, I just updated my issues list based on the current draft (that is, I didn't yet have time to scan for potential new issues). Most of the issues are editorial, but two of them IMHO really need to be addressed before the draft can be submitted (05-C05 and 05-E12). Also, the embedded RNC grammar now works for me with the standard Jing validator from James Clark's web site. Thanks! Best regards, Julian -- 05-C05, 4.15.3 processing model http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3 -06: http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.1.3.3 If the value of type ends with +xml or /xml, the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the src attribute is not provided, this would normally mean that the atom:content element would contain a single child element which would serve as the root element of the XML document of the indicated type. The statement about the src attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no src attribute). 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? Update -06: I'm still confused by the text. For instance: - is it intentional that 4.1.3.3 says ``If the value of type ends with +xml or /xml'', while 4.1.3.2 used ``If the value of type begins with text/ or ends with +xml''? - also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. point 4, make statements about situations where it comes with @src attribute? Maybe it's not a SHOULD requirement after all? 05-E02, Notational Conventions http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#RELAX-NG I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html Update -06: I think it would be good if all W3C references came with URLs. 05-E05, 3.2.2 atom:uri The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]. 06: http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.2 Directly point to RFC3986's section (here: 4.1). Update -06: I still think that spelling out the section number will make it easier to actually locate the definition. 05-E06, 3.2.3 atom:email http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.3 Its content MUST be an e-mail address [RFC2822]. Again, please refer directly to the definition. In this case, it seems to be section 3.4.1 (addr-spec production). 05-E08, 4.6.2 rel attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.6.2 06: http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.2.9.2 ...same name registered within the IANA Registry of Link Relations Section 9, and... Put the section reference into brackets. 05-E12, 11 references http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.references 06: http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.references Here's a producedural question: if we have normative references to the protocol and the feed discovery document, the spec won't get published until those are done, too. Is everybody aware of that? Update -06: we still have a normative reference to the feed discovery spec, which, according to http://tools.ietf.org/wg/atompub/, has expired. If this reference is expected to stay in, we'll have to actually finish that spec as well :-) 06-C01, 3.1.1 type Attribute http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1 This has been mentioned before...: as far as I can tell, it's far easier for recipients to process xhtml compared to html (no tag-soup parser needed), thus *any* kind of change that encourages xhtml would be appreciated. Update -07: I acknowledge that the WG is unable/unwilling to look at this topic again after att the discussions we had about it earlier in. I'll leave it here inside my issues list anyway so that my disagreement is at least recorded :-)
Re: PaceFeedIdOrSelf
Antone Roundy wrote: ... Proposal In section 4.1.1 of atompub-format-06, change this: * atom:feed elements MUST contain at least one atom:link element with a relation of alternate. To this: * atom:feed elements SHOULD contain at least one atom:link element with a relation of alternate. +1 (I just checked my two test feeds; one of which doesn't have an alternate version so currently I have to lie). And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. Fine with me as well. ... Best regards, Julian
Re: application/rss+xml
Bill de hÓra wrote: ... ultraliberal/+halfassedwebdav ... I guess I need you to explain that joke. Julian (confused) -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
new issues in draft -06, was: Updated issues list
..and here's a set of *new* issues I found while re-reading the draft...: 06-C01, 3.1.1 type Attribute http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1 This has been mentioned before...: as far as I can tell, it's far easier for recipients to process xhtml compared to html (no tag-soup parser needed), thus *any* kind of change that encourages xhtml would be appreciated. 06-C02, 3.1.1 type Attribute http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1 Here's a question. Is this...: summary type=html overlapping lt;bmarkup lt;islt;/b badlt;/i. /summary legal Atom? As far as I can tell, here we have a SHOULD level requirement to only transport well-formed HTML4 content, right? 06-C03, 3.3 Date Constructs http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.3 As others have pointed out, the regexp is incorrect (- characters in full-date part are missing). Also, I'm not sure whether it requires the timezone information; if it doesn't, this isn't what RFC3339 defines. In general, I find RFC3339 much easier to read: --snip-- date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac= . 1*DIGIT time-numoffset = (+ / -) time-hour : time-minute time-offset = Z / time-numoffset partial-time= time-hour : time-minute : time-second [time-secfrac] full-date = date-fullyear - date-month - date-mday full-time = partial-time time-offset date-time = full-date T full-time --snip-- 06-E01, 1.2 Example http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.1.2 Is it intentional that the example is inconsistently indented? 06-E02, 1.3 Notational Conventions http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.1.3 ...speaks about namespace prefixe*s* being defined; but then only defines a single one. 06-E03, 5.1 Digital Signatures http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.5.1 s/namespace IRI/namespace URI/ (or namespace name) 06-E04, 6.2 Extensions To the Atom Vocabulary http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.6.2 --snip-- considered foreign markup. --snip-- (quoting). 06-E05, 8.1 HTML and XHTML Content http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.8.1 See the security sections of RFC 2854 and HTML 4.01 for guidance. (use proper references) Best regards, Julian
Re: Broken RELAX NG Grammar in Appendix B of draft-06
David Powell wrote: Two more things I've just noticed: PersonConstructs aren't currently allowing extension elements. anyForeignAttribute and anyForeignElement are currently not used anywhere. Proposal for test procedure: - please publish an updated RNC file somewhere (on atomsub.org?) - those who already produce experimental atom-06 feeds, please check them with that RNC (my test feeds are http://greenbytes.de/tech/webdav/webdav.atom and http://greenbytes.de/tech/webdav/webdav-ietf.atom) Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Attributes on the xhtml:div wrapper
Tim Bray wrote: On Mar 17, 2005, at 1:08 AM, David Powell wrote: But, I think that we should disallow xhtml attributes on the xhtml:div -1, unless you can provide actual real examples of actual real problems that this prevents. --Tim The underlying issue here (afaik) is that we've been told that the mandatory is /not/ part of the content, thus I wouldn't expect recipients to store it in any way. So what happens if attributes carry inheritable information? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Attributes on the xhtml:div wrapper
Henri Sivonen wrote: On Mar 17, 2005, at 00:57, David Powell wrote: c) disallow XHTML attributes on the xhtml:div wrapper, but allow xml:lang. If you allow declaring the language, why do you disallow declaring the dominant writing direction (dir)? Shouldn't they be allowed or disallowed together? d) Get rid of the wrapper div. +1 (as far as I can tell, it makes things more complicated, not simpler) -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Status of draft-ietf-atompub-format
Robert Sayre wrote: Graham wrote: On 6 Mar 2005, at 5:15 pm, Paul Hoffman wrote: Your assumption is completely wrong. The WG will review the next draft before passing on to the IETF. The timing of the IETF meeting is completely inconsequential. Can you fill us in on what's happening with the new draft, and what are future timetable looks like? The draft has been submitted. We should be getting an I-D Announce message soon. OK, here are some preliminary comments based on what's available from http://www.atompub.org/2005/03/12/draft-ietf-atompub-format-06.html: - the RNC grammar is still unusable in that TRANG rejects the Schematron extensions; what do I need in addition to TRANG/JING to actually use that file? - after removing the Schematron extensions: the RNC still is broken (missing double quotes after 'text') - (after fixing that as well): atomPlainTextConstruct and atomXHTMLTextConstruct still use uppercased type names (in the collected RNC) - the current RNC doesn't check for xhtml:div content below XHTML text constructs. I've updated my experimental atom-06 feed at http://greenbytes.de/tech/webdav/webdav.atom. Feedback appreciated... Best regards, Julian
Re: Back on type=HTML, going a step farther...
Tim Bray wrote: On Mar 7, 2005, at 10:31 AM, Martin Duerst wrote: for some implementors, HTML is actually easier, if they are handing a chunk of bytes to an HTML rendering control, they'd rather not reconstruct the syntax from the infoset, they'd rather just take an opaque chunk of bytes. I really hope they don't take an opaque chunk of bytes, because if they do, they'll have no clue about the character encoding. Not true; if you can parse the XML to find the atom:content then you know the character encoding and can tell your HTML renderer. -Tim I think Martin was talking about the producer: if all he has is a chunk of *bytes*, there's no reliable way top put that into an HTML-typed text construct (you'll need characters, not bytes). Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Status of draft-ietf-atompub-format
Hi, apparently, the new draft (06) wasn't finished in time for submission before the meeting cutoff. As this draft is the one that's supposed to be submitted for publication (at least that's my understanding), wouldn't it make a lot of sense to make the current edits available for review (*before* it is committed after the end of the IETF meeting)? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Status of draft-ietf-atompub-format
Paul Hoffman wrote: As this draft is the one that's supposed to be submitted for publication (at least that's my understanding), wouldn't it make a lot of sense to make the current edits available for review (*before* it is committed after the end of the IETF meeting)? Your assumption is completely wrong. The WG will review the next draft before passing on to the IETF. The timing of the IETF meeting is completely inconsequential. OK, thanks for the clarification. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Back on type=HTML, going a step farther...
Thomas Broyer wrote: Hi there, First, let's introduce myself: I'm a 24 year-old French programmer living in Dijon, France. Some day, I'd have liked to create my blog but got stuck by all these RSS thingies and API stuff... I'm back now to syndication as a user and programmer, and found Atom as the new unified standard for syndication and web service API. Reading the Atom spec (draft -05), one thing shocked me: what is this type=HTML for? ... I agree with what you say, but I fear this topic has been discussed and dicussed again in the past with no result. For some reason, people seem to prefer a format where bad data (tag soup) is allowed, and the task to fix it is put onto the recipients rather than the creators. For me it's very obvious that this is the wrong approach -- if you can require the recipients to do that, you can also require the same responsibility from the producers. Anyway, I recently made a much more modest request that the spec should state that XHTML is preferred over HTML (because many recipients will not be willing to process tag soup, so in the best case formatting is lost). It seems that we can't even get a consensus for that, which is really disappointing considering the expectations I had 18 months ago :-( Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Back on type=HTML, going a step farther...
Robert Sayre wrote: Agree w/ Tim. Also, HTML4 enjoys far better rendering support than XHTML does. That's true (in IE), but that's just a serialization problem. Nobody said that recipients should emit that XHTML directly to HTML controls. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: [Fwd: draft-reschke-http-addmember-00]
Lisa Dusseault wrote: ... I think ADDMEMBER would be worthwhile if it did have more of an extensibility model and provide the ability to support specialized applications. For example, some calendar servers need to reject non-iCalendar formatted submissions. ADDMEMBER reminds me a lot of MKRESOURCE if it leans in that direction. Well, we just killed MKRESOURCE for good reasons :-) Anyway; nothing is preventing a server to restrict the applicable content types for ADDMEMBER... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
[Fwd: draft-reschke-http-addmember-00]
(fyi) Original Message ... To: [EMAIL PROTECTED] ... Hi, recently different communities (caldav/groupdav, atompup (protocol part)) have been discussing how to use HTTP to author new resources when the URL namespace is completely server-controlled, thus PUT just doesn't fit well. A simple approach would be to define a new HTTP method which is *almost* like PUT, except that the server chooses the URL to create (and returns it in the Location header). I've submitted a first draft as draft-reschke-http-addmember-00. Note that it also contains an appendix covering possible alternative approaches. Feedback appreciated, Julian HTML version: http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html Latest edits will be at: http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: That's what I want to change. I've updated the Pace to make this clearer. I replaced the abstract completely, and added one sentence to the proposal. New abstract: Given that common practice is to include this element, making it mandatory makes things clearer to both people who are producing consuming tools based on the spec, and people who are producing new feeds based on copy and paste. New spec text: The xhtml:div element itself MUST NOT be considered part of the content. I find it a bit problematic to use common practice in Atom feeds as justification for spec changes. Let's make the spec as clear and simple as possible. If this is in conflict with common usage in experimental Atom feeds, so be it. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Nor am I. The question is what's the best way to enhance the spec. One alternative suggestion was made by Martin Dürst in http://www.imc.org/atom-syntax/mail-archive/msg13531.html: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content element and specifying the XHTML namespace on that div element. Here are some examples: ... [use proposed examples] There are other ways to declare the namespace URI for XHTML content; this specification does not limit the placement of such declarations in any way. My issue with that wording is that it doesn't make it clear whether the xhtml:div that is added is to be considered a part of the content or not. I'd assume it's part of the content because that's what the spec currently says. Put another way, how does the consumer know that if a given xhtml:div element is part of the content, or was added per the above? It is, unless the spec says otherwise. Julian, you previously said Let's make the spec as clear and simple as possible. How about this: xhtml:div is required. xhtml:div is not part of the content. Clear. Simple. And difficult to get wrong. Well, but not sufficient as spec text right? To summarize my p.o.v.: - the spec shouldn't require any specific container element for XHTML content, - the spec should warn people about that the child elements MUST be in the XHTML namespace if the recipient is supposed to interpret them as as XHTML markup, - whether or not a feed producer puts in a div container doesn't seem to be relevant to me as it doesn't affect the semantics of what the text construct carries. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Robert Sayre wrote: Julian Reschke wrote: So do you think we'll have to live with that, or should the spec be clarified/changed to reduce the chance of people getting it wrong? I think Sam's approach is best. The objections are all impractical pedantry. I think the proposal won't really help for cases where people don't know what they do and/or use the wrong tools, but adds completely unnecessary complexity for everybody else. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Julian Reschke wrote: Sam, thanks for the long reply. I'll try my best to dig it and to offer constructive remarks... To summarize my p.o.v.: - the spec shouldn't require any specific container element for XHTML content, We continue to talk past one another. The above line is key. Some examples might help. Perhaps once we are actually understanding each other's points, then we can work backward from there to spec text. So, suppose my XHTML content is: pWhat a nice day!/p My XHTML container element is p. That is completely my choice. It is not required by the spec. Yep. Now if I place that inside an atom feed, I'm going to get something like this (heavily elided, all namespace details omitted): feed entry summary pWhat a nice day!/p /summary /entry /feed Yep. Depending on the how the question is phrased, one could take the position that feed, entry, and summary are container elements. Or not. Again, depending on how the question is phrased. Fine with me. I don't believe that these elements are the ones that you have an issue with. Correct? Yes. Now, consider a different document, again heavily elided, etc: feed entry summary div pWhat a nice day!/p /div /summary /entry /feed The key difference between these two documents is that instead of three elements around which there should be no issue, there now are four. But for some reason, this causes a big controversy. My theory is that the controversy is that people initially assumed that this div element was to be considered part of the content and not part of the format. And thereby was mandating that all content have a given container element. An entirely unreasonable mandate. Well, the current spec says it's part of the content. I personally feel it really doesn't matter. Adding DIVs around XHTML content doesn't change the semantics of the content, in particular if it doesn't carry any additional attributes. So, I wouldn't have any problems with recipients that collapse multiple nested xhtml:div elements into one or none (in absence of other attributes on it). I agree that this would be an unreasonable mandate. But I don't want to force a top level container element for the xhtml, I want to define a bottom level container element in the format for the xhtml. There is a big difference. It's still hard to see the difference, It's certainy not obvious on the syntactical level, and at the end of the day, that's what we are discussing here, right? The difference between four feed container elements and mandating that all xhtml content have a uniform top level container element. Which again, I will agree is an entirely unreasonable assumption. - - - On the optimistic presumption that you are with me so far, I'll press on. What desirable characteristics are there for feed container Not entirely, but trying :-) elements in this circumstance? To answer that question, it is important to understand how CMS software tends to be implemented. In particular, how they are layered. This is difficult as there isn't any one reference implementation that we can consult. We also need to consider software which isn't written yet. As I said, this is diffuclt. But we can observe common problems that people have had, and try to engineer a solution that avoids them. I hold the belief that if somebody writes a simple and clear spec that a significant number of people get wrong, that we are looking at a spec bug. Sure. But, are we looking at the whole set of implementors, or only those who actually read the spec? We all know that those sets aren't identical... Enough hand waving, onto the problem at hand. What we are looking at here is an xhtml fragment. Not a complete xhtml document, but some fragment of a web page. Yes. Now, fragments tend not to exist independent of a context. And in virtually all xhtml documents I have seen (including the ones I produce), any fragment presumes that the xhtml namespace was defined as the default namespace earlier in the document (in particular, on the document element). Well, that depends how you define fragment. For instance, I can use XSLT to produce that fragment and I certainly don't have to make any assumptions about default namespaces. The XSLT processor cares for me. The same thing applies when serializing a node set from an namespace-aware DOM (at least that's what I'd expect and MSXML has been doing for years now). So, a desirable characteristic for a container element would be one in which the default namespace can be set. I disagree that this is important, but the atom text constructs do have that characteristic already. At this point, the discussion can fragment into any number of different directions. - - - One is for those who view XML as merely one potential serialization format, and something that their tool takes care of for them. For them
Re: type=HTML
Paul Hoffman wrote: ... Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Why would one be preferred over the other? They both have their strengths and weaknesses. We're not in the business of saying this newer one is better. That's an interesting statement. Does type=HTML have *any* strengths compared to type=XHMTL (expect being easier to produce if you don't have XHMTL in the first place?). Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: type=HTML
Paul Hoffman wrote: At 5:34 PM +0100 2/9/05, Julian Reschke wrote: That's an interesting statement. Does type=HTML have *any* strengths compared to type=XHMTL (expect being easier to produce if you don't have XHMTL in the first place?). That's certainly a big one. Also, many folks don't understand the requirements for XHTML that could cause them to create text that will be rejected as badly formed. In other words, HTML is just easier. I'll agree that it's easier to produce for those who don't understand XML. But shouldn't we recommend XHTML for those who *do* understand XML/XHTML (and actually read the spec)? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: type=HTML
Paul Hoffman wrote: At 7:06 PM +0100 2/9/05, Julian Reschke wrote: I'll agree that it's easier to produce for those who don't understand XML. But shouldn't we recommend XHTML for those who *do* understand XML/XHTML (and actually read the spec)? Unless that suggestion gains better interoperability for Atom, no. I'll expect more clients to be able to handle XHTML than HTML tag soup. So yes, that would enhance interoperability. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Bill de hÓra wrote: Sam Ruby wrote: If this Pace is not adopted, the following predictions can be made: 1) Graham (who uses proper XML tools) will have to do more work. I'd like to see a concrete example where this is a problem. As far as I can tell, the content construct itself can be considered the container, so whether or not a mandatory DIV element is present, there will always be a useable container element. 2) Tim (who uses string concatenation) will have to do more work. Nothing changes for Tim, he can continue to produce the output he's producing currently. 3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations. Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements. 3) More feeds will be invalid (content in atom namespace) Perhaps I misunderstand... but this shouldn't result in invalid Atom feeds ever - content areas should be able to hold any-namespace not any-namespace-atom-namespace. Worst case is mangled content when the content is lifted out using namespace aware tools. In other words, the container markup format is just dandy, but the content they carry is potentially trashed. If we condone default namespaces this is what we can expect to happen. We discussed warning people about this broken piece of XML technology last year and it was punted to an Implementors Guide - I'm somewhat unsympathetic now if we find ourselves bitten. Perhaps I overreached with the word invalid, but I am of the opinion that if the type is XHTML that the content should be an xthml fragment. atom:b and atom:strong elements are examples of things which one would not expect to find in xhtml. Yes, but there are many other things people may get wrong when producing Atom. In particular, I would tend to trust those who do generate XHTML instead of HTML to get namespace declarations right as well. Below are some comments that I just added to the Pace: - Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. - if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Nothing changes for Tim, he can continue to produce the output he's producing currently. What Tim is syndicating does not match the content on his site. Without this Pace, the div element would need to be considered part of the content. What difference does this make in practice? HTML defines DIV as... These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. (http://www.w3.org/TR/html401/struct/global.html#edef-DIV) 3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations. Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements. Fair. However, a globally scoped XHTML namespace declaration will require every xhtml tag to be explicitly namespaced. (unless we make it the default namespace, which usually won't make sense). - Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. Nothing in this pace requires such a declaration. When a Text construct or atom:content's type is XHTML, require it to have a single xhtml:div as a child, and require that div to declare the XHTML namespace. Am I looking at the wrong pace? (http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv) - if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry. Are you suggesting that the following would need to be required for symmetry? lt;divgt; ... lt;/divgt; Yes. Suggesting this seems petty. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: type=HTML
Sam Ruby wrote: Julian Reschke wrote: (http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1) The spec currently says: If the value of type is HTML, the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by software that knows HTML. The HTML markup must be escaped; for example, br as lt;br. The HTML markup SHOULD be such that it could validly appear directly within an HTML DIV element. Receiving software which displays the content MAY use the markup to aid in displaying it. Is there anything that we can say about what recipients should do if they are not prepared to tag-soup-parse HTML content (such as something based on XSLT1 in Mozilla or running in a size-constrained environment (does MIDP come with an HTML parser)? Skip the entry? Do not display the content? Display the content including the escaped markup as plain text? I would suggest stripping the tags. In Perl, something like this: s/.*?//g Thanks. Are we 100% confident that whatever results from that replacement can be safely embedded? For instance, what about script tags? Can they contain potentially dangerous code that would execute without being referenced from somewhere? Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Depending on the target environment, stripping the elements in XHTML may also be appropriate. Sure, but for XHTML, the XML parser already contains the necessary machinery. Anyway, the spec offers to alternatives (HTML and XHTML) that cover similar use cases. I think it would be good if it made a recommendation at least for those cases, where the producer already has XHTML content. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceXhtmlNamespaceDiv
Anne van Kesteren wrote: Henri Sivonen wrote: -1 on PaceXhtmlNamespaceDiv -1 from me as well. It is hack which might be useful for publishing systems (and perhaps aggregators) who do not use the right tools to generate a valid Atom file anyway. Same here: -1 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: xsd:dateTime vs. RFC 3339
Tim Bray wrote: On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg 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 Constructs in terms of W3C XML Schema Part 2 than RFC 3339. Now I agree as well. I tend to agree as well; in this case, the fact that this is an XML vocabulary is probably more relevant than the fact that it's an IETF RFC. So can we please have a Pace to call out to XSD? I'm pretty sure that implementors would just use the libraries and The Right Thing Would Happen. -Tim Risking that I sound like a broken report...: xsd:dateTime allows a superset of what we can represent in RFC3339 (I'm talking about semantics, not syntax here). So if we *don't* profile it, the spec will need to explain how to obtain an ordering from a set of atom:updated timestamps where some are lacking the timezone information. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: xsd:dateTime vs. RFC 3339
Robert Sayre wrote: I would tend to agree. Can we have that regex go in the Pace itself? That would make the proposal pretty much editorial, since the set of allowed timestamps would be the same (right?). As long as the set of allowed timestamps and their semantics is the same, that's fine with me. I still have doubts why this is better than sticking with the RFC version, though :-) Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 XML Schema Part 2 than RFC 3339. I propose that we change the spec to do so. I agree. I was just writing a protocol implementation in Ruby On Rails (CRUDs very fast, btw). When I got to the part on date formats, I used xsd:dateTime code that was already done, figuring that's what everyone else will do. But in that case, we'll need to profile xsd:dateTime. For instance, that one allows timestamps without timezone (with a distinct meaning!). Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 Constructs in terms of W3C XML Schema Part 2 than RFC 3339. Strongly agree. Also, we have an unresolved issue with historic Livejournal entries, which do not have timezones. XML Schema explains exactly how to So what does it recommend? handle those. We can have a SHOULD for timezone info, with an explanation of what you lose without that. So what is a recipient of a timestampe without TZ info supposed to do with it? Throw it away? Default to UTC? -1 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 MUST be valid xsd:dateTime
values and MUST also match the following regular expression:
[0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?(Z|[\+\-][0-9]{2}:[0-9]{2})
(Expressed for my own testing purposes in XML Schema pattern syntax.)
Sounds good to me, except that I would keep the reference to RFC3339
(semantics are the same, but I think RFC3339 is more readable).
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Entry order
Tim Bray wrote: On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Except for, Atom entries have a *compulsory* updated date. So I have no idea what semantics you'd attach to the natural order... -Tim Nit: they want have an ordering anymore if we allow updated dates with missing timezone information (i.e., dates with a 24h uncertainty). Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 say 1) ...SHOULD use application/atom+xml... ...then, if you don't want to... 2) ...SHOULD use application/xml... ...then finally... 3) otherwise MAY use text/xml. That is a problem in itself. Either we mandate a specific content type or we don't (I think we should). If we mandate one, we should say that behaviour of documents served with a different type is simply undefined. Note that most of the nasty RFC3023 problems only apply to text/*, in particular I don't see why we would want to RECOMMEND to use a charset parameter on application/* content types. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 many bugs. Check it out at http://www.tbray.org/ongoing/ongoing.atom Same here (http://greenbytes.de/tech/webdav/webdav.atom). I find your use of opaquelocktokens intriguing. My reading of the spec is that opaquelocktokens are sequences of 8, 4, 4, 12 hex digits, separated by dashes, optionally followed by a path. In place of a path, I see what appears to be a timestamp. Can somebody cite a reference which permits such uris? The timestamps I am using are legal path components, according to RFC2068, section 3.2.1 (which RCF2518's definition for the opaquelocktoken scheme refers to). Or am I missing something? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 publication process, this means that draft-ietf-atompub-format can't be published until the protocol spec is ready as well. One alternative I'd like to mention is to remove all references to the protocol spec from the document spec including the service URI definitions, and to move the latter as extension elements into the protocol spec. This would essentially de-couple the publication process. Thoughts? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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. For the record: I made that proposal *although* I like the protocol bit a lot. I just want us to be able to progress both specs independently of each other. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2.p.4: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate.' 05-C05, 4.15.3 processing model http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3 If the value of type ends with +xml or /xml, the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the src attribute is not provided, this would normally mean that the atom:content element would contain a single child element which would serve as the root element of the XML document of the indicated type. The statement about the src attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no src attribute). 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 a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2.p.3 needs to be adjusted. I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Aren't they considered to be stable? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Sam Ruby wrote: Julian Reschke wrote: atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (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: atomTitle type=XHTML div xmlns=http://www.w3.org/1999/xhtml;Less: em lt; /em/div /atomTitle The above is similar to your example, but not _identical_ to your example, given the current spec. Well, the current spec absolutely allows people to stick in the div element. It just doesn't require them to do it. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 would make the spec simpler with little additional verbosity in the instance documents. I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Aren't they considered to be stable? I couldn't find any standards track documents that reference them. I guess we could link it up in the HTML document, but note that the W3C docs are linked either. For instance http://www.w3.org/TR/xhtml2/references.html#ref_RELAXNG and http://greenbytes.de/tech/webdav/rfc3470.html#RELAX-NG. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format -05.html#rfc.section.4.15.2.p.3 needs to be adjusted. You're correct, but the WG should decide which sentence will change. Huh? What's the issue? I just stared at that text for a couple of minutes and didn't get it. -Tim As far as I understand the spec, 4.15.2 (last sentence) says it's a SHOULD, 4.15.3 (5.) says it's a MUST. I think the fact that both sections say something about the same thing is the problem that needs to be fixed. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 the record, I'm opposed to it, too. The spec is already saying this: 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 completely useless. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 consensus can be found on this pace. I'm in favor of it. My current parser doesn't let me pull out all childen of element x in one go, so I have to step through in a really hacky way. With this I can just grab the div. That's an implementation issue that shouldn't affect the format. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 completely useless. what's missing though is guidance that the XHTML text and markup needs to be in the xhtml namespace, and not just plonked in there by a crude template-style publisher. that is, it needs to be clear from the spec that this is wrong: content type=XHTMLHere is a bbold statement/b/content ...at least it's not what the producer probably intends. Given the mass of content which is published via crude string concatenation template driven CMS products, this is something we need to address. As it is at the moment, a naïve reading of the spec suggests that the above atom XML is valid because the content element *does* contain XHTML text and markup that could validly appear directly within an xhtml:div element. By the way, are we assuming that the reader is meant to assume that the namespace prefix xhtml has been bound to the xhtml namespace? These are good points, so this should be clarified (independently of whether we require div or not). Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 imaginary. I may be moving toward agreement with Graham, but the statement above is incorrect. Sam (or was it Mark) demonstrated clearly that if you use the URI.equals() (or equivalent) method in many modern programming languages, you will get all sorts of canonicalization done without asking, and it is very likely that lots of programmers will do this. How about this: The only comparison method Atom Processors MUST support is character-by-character comparison [RFC3986]. Atom Processors MAY perform additional scheme-specific comparisions. If an Atom processor MUST support char-by-char, what would be the point of supporting anything else? One comparison method should be enough, shouldn't it? If you do this: http://Example.org/thing http://example.org/thing You cannot count on a positive or negative, and you are sloppy. Why can't I count on the result, if the spec says I can? (not that I would recommend to do that in the real world) Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 the format. Perhaps more material than anything else. -Tim OK, I'll try to rephrase: changing the protocol format because one implementor says that this makes it easier to implement IMHO is a bad idea. Of course things look differently if this issue affects more platforms/parsers/toolkits. So yes, more information is needed. Best regards, Julian -- green/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 http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.2 Inconsistencies: - version attribute (whitespace) - rel attribute is missing 05-C02, 3.1.1, type attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1 Suggested examples for TEXT, HTML and XHTML: a title containing the string Less: , where the less sign displays emphasized when possible.. atomTitle type=TEXT Less: lt; /atomTitle atomTitle type=HTML Less: lt;em amp;lt; lt;/em /atomTitle atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (hope I got these right). 05-C03, 3.1.1, type attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1 The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Add reference to XHTML1 (http://www.w3.org/TR/2002/REC-xhtml1-20020801), section A). 05-C03, 4.3, atom:head http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3 'The version identifier for this specification is draft-ietf-atompub-format-05: do not deploy' Spelling of the version attribute inconsistent with section 4.1.1. 05-C04, 4.11 atom:host http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.11 Like others, I'm not sure I understand what this is for. I think one sentence of rational would make the spec easier to absorb. 05-C04, 4.15.2 atom:content http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2 Like others, I find the syntactic impact of allowing it either to be in-line or out-of-band confusing. I don't feel strongly about this, but using two distinct XML elements instead might make things easier. 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. I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? 05-C05, 4.15.3 processing model http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3 If the value of type ends with +xml or /xml, the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the src attribute is not provided, this would normally mean that the atom:content element would contain a single child element which would serve as the root element of the XML document of the indicated type. The statement about the src attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no src attribute). 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? 05-C06, B RelaxNG schema http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.B I tried to use the schema to validate a feed that I generated and had the following problems: - my version of trang (20030619) didn't accept the Schematron rules -- what else do I need to use RNC as reprinted? - the namespace name doesn't match the current one 05-E01, todos For instance: http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.p.4 Recommend to do them using rfc2629bis's cref element. 05-E02, Notational Conventions http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#W3C.REC-xml-infoset-20011024 Should't we refer to http://www.w3.org/TR/2004/REC-xml-infoset-20040204/? http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#RELAX-NG I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html 05-E03, Notational Conventions A collected schema appears in an informative appendix. (refer directly by section/appendix number). Same for some other intra-document references. 05-E04, Atom Documents ... relative reference [RFC2396bis] present in an Atom... RFC2396bis has been published as RFC3986. 05-E05, 3.2.2 atom:uri The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]. Directly point to RFC3986's section (here: 4.1). 05-E06, 3.2.3 atom:email Its content MUST be an e-mail address [RFC2822]. Again, please refer directly to the definition. In this case, it seems to be section 3.4.1 (addr-spec production). 05-E07, 4.2 atom:head http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2 The atom:head element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. I think we're overdoing it here a bit and loose readability. I suggest to remove the
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 -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? It does. The idea is that textual content is more valuable if it's right there in the feed than if you have to go elsewhere to get it. -Tim I agree that this is the case, but does that require a SHOULD-level requirement? Explaining the issue instead of just trying to enforce it may lead to better results... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 interoperability problems. I don't see how application/xml relates, but if I were forced to make the choice, I would drop atom:info. I have ABSOLUTELY NO IDEA what it is that Sam and Rob are arguing about. I suspect I'm not the only one. Could someone please explain the problem in basic terms? Thanks, Robert. Sam wants the spec to guide the feed validator when it encounters feeds served with media types other than Atom's. I don't want the spec to talk about HTTP or other media types. I think it's enough to say that if it doesn't come with the right media type, it's outside the scope of the spec (same for wellformed-ness errors and so on...). Sam is saying atom:info is used only when feeds are served with the wrong media type, so we shouldn't include it unless we are going to cover other media types. I maintain that atom:info has uses when Atom feeds are served as application/atom+xml. Interesting. Can anybody summarize what atom:info is *currently* used for? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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. Requiring a div element addresses a number of needs - it makes it easier to get the namespace right, and it succinctly provides a rather good hint as to what child elements are valid. That's what the spec already says, doesn't it? - http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1.p.6 ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 that no resolver is required to resolve all URIs or IRIs) ... OK, thanks for making me aware of this subtle change. ... Regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 said on the list, after this set of Paces is evaluated, we believe we're ready to go to IETF last call. We have to finish sometime, and on our milestone is a reasonable target. Aren't you planning to do a working-group last call before that? ... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 developers of clients that run on somwehat constrained devices. Also; I sypmathize with supporting IRI, but that shouldn't mean it needs to replace any usage of URIs (for instance, I also think that the introduction into XMLNS 1.1 was a mistake). So: -0. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 use IRIs. Replacement is definitely not the right term. Let's disagree here. If the spec currently says URI and is supposed to say IRI, we *are* replacing URI by IRI (even if every URI is an IRI). (for instance, I also think that the introduction into XMLNS 1.1 was a mistake). Well, I might agree that it was a mistake. Observable behavior for most implementations (in particular XSLT implementations, where you most easily can test actual namespace behavior) allows IRIs in namespaces anyway, so this could just have been a clarification to the XMLNS 1.0 spec, rather than bumping up the number. 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 without producing invalid HTML. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
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 reference is the correct terminology used in RFC2396bis. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
