Jakarta FeedParser Cometh

Hey gang... I'm fast approaching a 0.5 release of Jakarta FeedParser http://jakarta.apache.org/commons/sandbox/feedparser/ And thought I'd solicit some feedback: I'm also looking for some better unit tests for Atom 0.5. Hopefully something under a more liberal license . The unit tests within the

Re: Dereferencing Identity Constructs

On 31/1/05 3:22 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > "When using to ascertain whether two Atom entries or feeds > are the same, such operations MUST be based only on the URI character > strings, and MUST NOT rely on dereferencing the URIs." +1

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

On Jan 30, 2005, at 8:09 PM, Robert Sayre wrote: Yay! Let's drop atom:host. +1 oh yes please, I always thought it was lame-ass. -Tim

Re: Dereferencing Identity Constructs

On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote: The content of an Identity construct SHOULD NOT be dereferenced, even when it comes from a normally dereferencable scheme. There is no requirement for the content to represent a URI where a version of the feed or entry may be found. I'm

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

If we don't want Atom to be processed by "generic XML processors and technologies" and dispatched accordingly, then the correct course of action would be to choose a media type without the "+xml" suffix. I still don't see how this relates to atom:info. Robert Sayre Mark Nottingham wrote: RFC 30

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

Joe Gregorio wrote: I believe atom:host is the long lost descendent of atom:ipaddr, which came from the problem I had implementing Atom on wiki, where the 'author' of an entry can be difficult to pin down and the ip address may be the only information available. If atom:host is what the 'solution'

Re: Dereferencing Identity Constructs

On Sun, 30 Jan 2005 22:30:16 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Paul Hoffman wrote: > > > > At 5:11 PM + 1/30/05, Graham wrote: > >> > >> The content of an Identity construct SHOULD NOT be dereferenced, > >> even when it comes from a > >> normally dereferencable schem

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

RFC 3023, Section 7: This document recommends the use of a naming convention (a suffix of '+xml') for identifying XML-based MIME media types, whatever their particular content may represent. This allows the use of generic XML processors and technologies on a wide variety of different

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

Mark Nottingham wrote: So, the relevant question seems to be whether any browsers do something interesting with +xml media types; No, the relevant question is whether +xml media types can be reliably dispatched without any knowledge of a specific scheme. I don't know the answer, but I do know t

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

On Sun, 30 Jan 2005 18:11:56 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > I'm not going to lie down in the road to get rid of atom:host, if there > are a lot of people that want it badly. However, it should be more > completely specified; i.e., some mention in security considerations, >

Re: URI canonicalization

On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: > > Paraphrasing Tim [1] "I'm definitely -1 on losing 3.5.1, the > canonicalization warning is a hard-won compromise and seems to cause > no-one any pain." > > We discussed this at extreme length, and no new arguments have b

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

Good question. If it's served with Atom's media type, most (but not all, I suspect) browsers will ask how to dispatch it, or just save the file; some might optimistically try to handle it themselves, based on the "+xml". In the case that they dispatch it elsewhere (including the local filesyst

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

Mark Nottingham wrote: On Jan 30, 2005, at 7:03 PM, Graham wrote: On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote: which is the same feed, but with atom:info replaced by a 'foo' element. Even better, you can drop foo and put the xhtml div as a direct child of feed. Then use feed > div as the sel

Re: Dereferencing Identity Constructs

Paul Hoffman wrote: At 5:11 PM + 1/30/05, Graham wrote: The content of an Identity construct SHOULD NOT be dereferenced, even when it comes from a normally dereferencable scheme. There is no requirement for the content to represent a URI where a version of the feed or entry may

Re: Dereferencing Identity Constructs

On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote: I'm +1 on this, but would be fine if the WG doesn't want to change. Graham's wording is more useful to an implementer who wasn't on the mailing list last year (or was on and skipped over the permathreads). Ditto. (Actually I think even having a se

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

On Jan 30, 2005, at 7:03 PM, Graham wrote: On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote: which is the same feed, but with atom:info replaced by a 'foo' element. Even better, you can drop foo and put the xhtml div as a direct child of feed. Then use feed > div as the selector. Nice! And, if

Re: Obs on format-05

Hey Bill, Thanks for the detailed, well-justified and precise comments; this is a very helpful format to submit them in (hint, hint). Some selective feedback; On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: Replace: [[[ Note that the choice of any namespace prefix is arbitrary and not semantic

Re: Dereferencing Identity Constructs

At 5:11 PM + 1/30/05, Graham wrote: 3.5.1 Dereferencing Identity Constructs The content of an Identity construct MAY be dereferencable (e.g. an HTTP URI). However, processors MUST NOT assume it to be dereferencable. The first sentence doesn't say anything. The second is good but do

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

On 31 Jan 2005, at 2:40 am, Mark Nottingham wrote: which is the same feed, but with atom:info replaced by a 'foo' element. Even better, you can drop foo and put the xhtml div as a direct child of feed. Then use feed > div as the selector. And, if you use XSLT, it's also possible to do it all in-s

Re: how to write spec language for language variants?

At 5:09 PM +1100 1/29/05, Eric Scheid wrote: nitpickers welcome. I have this spec text in my draft Pace... atom:head elements MAY contain one or more atom:foo elements, so long no two atom:foo elements have the same combination of atom:hreflang, xml:lang, or atom:type. I also considered wr

Re: Comments on format-05

OK. So, why is it necessary to standardise this element? Look at http://www.mnot.net/test/atom.xml which is the same feed, but with atom:info replaced by a 'foo' element. Because the atom document has to reference the CSS anyway, it's entirely reasonable to have the css specify what element to

Re: Posted PaceTextRules

On 31 Jan 2005, at 1:43 am, Tim Bray wrote: Currently, the draft says *nothing* about xml:space (unless I'm mis-using the search function). If you read the specification for xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says is that this is a message from the author to downs

atom:host [was: Comments on format-05]

I'm not going to lie down in the road to get rid of atom:host, if there are a lot of people that want it badly. However, it should be more completely specified; i.e., some mention in security considerations, and also, more information about the association. Right now, it's just "domain name or

Re: URI canonicalization

On 31 Jan 2005, at 1:31 am, Robert Sayre wrote: Suppose your user is subscribed to a feed containing 1000 entries. One day, the host name is no longer capitalized. Are you going to put 1000 new, duplicate entries in front of the user? Yes. They have different ids as defined by the spec. If you th

Re: Posted PaceTextRules

On Jan 30, 2005, at 5:00 PM, Graham wrote: -Proposal Add "xml:space attributes appearing on Text constructs or their parents MAY be ignored by processors" to 3.1 Text Constructs. Currently, the draft says *nothing* about xml:space (unless I'm mis-using the search function). If you read the speci

Re: URI canonicalization

Graham wrote: On 31 Jan 2005, at 12:43 am, Robert Sayre wrote: How about "Make sure your id is unique from a character-by-character perspective, but also unique in the face of scheme-specific comparisons". That is, don't lean on scheme-specific comparisons to match URIs, but they don't have to b

Re: URI canonicalization

On 31 Jan 2005, at 12:43 am, Robert Sayre wrote: How about "Make sure your id is unique from a character-by-character perspective, but also unique in the face of scheme-specific comparisons". That is, don't lean on scheme-specific comparisons to match URIs, but they don't have to be canonical ei

Re: URI canonicalization

On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: We discussed this at extreme length, and no new arguments have been brought forward. Rough consensus does not mean absolute consensus. Thank you. We've discussed this too much already. Please let's leave this horse; it'

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

On Sun, 30 Jan 2005 22:06:23 +0200, Henri Sivonen <[EMAIL PROTECTED]> wrote: So how many European sites besides the EU have the resources to provide translations of the *same* content in multiple languages at the same time? The company I work in (the Norwegian Broadcasting Company), for instanc

Posted PaceTextRules

http://www.intertwingly.net/wiki/pie/PaceTextRules -Abstract Tighten up rules on processing text to ensure interop between apps -Status Open -Rationale Plain text may be interpreted and displayed in various different ways. Similarly text in the source may be formatted in many different ways. Clea

Re: PaceOrderSpecAlphabetically

On Sun, 30 Jan 2005 12:34:42 -0500, Sam Ruby <[EMAIL PROTECTED]> wrote: Order the Element Definitions in the specification alphabetically. Sounds like a very good idea. +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»

Re: PaceXhtmlNamespaceDiv posted

On Sun, 30 Jan 2005 17:57:57 +, Graham <[EMAIL PROTECTED]> wrote: 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. You can't grab 'atom:content/*[1]' or somethi

Re: URI canonicalization

Graham wrote: On 31 Jan 2005, at 12:16 am, Robert Sayre wrote: Graham wrote: Yeah, that's a horrible loose end to leave hanging. No, it isn't. URI comparison is not our problem, and what our spec says about it doesn't matter a bit. Yes it is times one million. Ha ha I win et cetera Defining rule

Re: URI canonicalization

On 31 Jan 2005, at 12:16 am, Robert Sayre wrote: Graham wrote: Yeah, that's a horrible loose end to leave hanging. No, it isn't. URI comparison is not our problem, and what our spec says about it doesn't matter a bit. Yes it is times one million. Ha ha I win et cetera Defining rules for ID compari

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: I suspect that once people see some examples, objections will surface. I've included an example of each approach, so people can compare the two methods. I have not positioned them as spec text. The spec requires more examples no matter which approach the WG chooses. Good examp

Re: URI canonicalization

Graham wrote: On 30 Jan 2005, at 11:43 pm, Eric Scheid wrote: what? and "Atom Processors MAY perform additional scheme-specific comparisions" won't lead to stupid arguments? Yeah, that's a horrible loose end to leave hanging. No, it isn't. URI comparison is not our problem, and what our spec says

Re: PaceOrderSpecAlphabetically

--On January 30, 2005 12:34:42 PM -0500 Sam Ruby <[EMAIL PROTECTED]> wrote: > > == Abstract == > Order the Element Definitions in the specification alphabetically. +1. Yes, please. It works fine for the HTTP spec. wunder -- Walter Underwood Principal Architect, Verity

Re: URI canonicalization

On 30 Jan 2005, at 11:43 pm, Eric Scheid wrote: what? and "Atom Processors MAY perform additional scheme-specific comparisions" won't lead to stupid arguments? Yeah, that's a horrible loose end to leave hanging. The spec should (nay, MUST) mandate a method of comparing Identity Constructs which wil

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I gather that a format-05 compatible feed, thus: I suspect that once people

Re: Comments on format-05

Robert Sayre wrote: Mark Nottingham wrote: * 4.11 The "atom:host" Element -- I'm surprised to see this in an IETF specification; people are going to make bad assumptions about the content of this, and violate layering to populate it. At the VERY least, I'd expect to see text in Security Consider

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

On 30 Jan 2005, at 8:06 pm, Henri Sivonen wrote: So how many European sites besides the EU have the resources to provide translations of the *same* content in multiple languages at the same time? How many of those can't provide multiple feed links and really want to stuff everything in a single

Re: Obs on format-05

Sam Ruby wrote: Bill de hÓra wrote: reason: we don't need to tell people what they can do with TEXT once we tell them what it is. Often times the use of MAY is advisory to the producer. This is one of those cases: if you are expecting mono spaced fonts, you might want to consider using either

Re: Obs on format-05

Tim Bray wrote: On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] I'm definitely -1 on losing 3.1.1, the text construct is a hard-won compromise and seems to ca

Re: URI canonicalization

Eric Scheid wrote: On 31/1/05 10:16 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: I agree with you in principle, but I find the current text unrealistic. It's just fodder for stupid arguments. what? and "Atom Processors MAY perform additional scheme-specific comparisions" won't lead to stup

Re: URI canonicalization

On 31/1/05 10:16 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > I agree with you in principle, but I find the current text unrealistic. > It's just fodder for stupid arguments. what? and "Atom Processors MAY perform additional scheme-specific comparisions" won't lead to stupid arguments? Here's

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

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

Re: URI canonicalization

Eric Scheid wrote: On 31/1/05 6:17 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: "Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. Processors MUST compare Identity constructs on a character-by-character basis in a case-sensiti

Re: URI canonicalization

On 31/1/05 6:17 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> "Instances of Identity constructs can be compared to determine whether >> an entry or feed is the same as one seen before. Processors MUST >> compare Identity constructs on a character-by-character basis in a >> case-sensitive fashi

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

--On January 30, 2005 10:06:23 PM +0200 Henri Sivonen <[EMAIL PROTECTED]> wrote: > > So how many European sites besides the EU have the resources to provide > translations of the *same* content in multiple languages at the same time? Pretty common in Quebec. We see English and Spanish in the US

Re: Comments on format-05

Julian Reschke wrote: 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 re

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

Julian Reschke wrote: 05-C01, 1.2 Example Inconsistencies: - version attribute (whitespace) Will fix. - "rel" attribute is missing The rel attribute is optional and the relation is considered to be "alternate"

Re: how to write spec language for language variants?

Eric Scheid wrote: atom:head elements MAY contain one or more atom:foo elements, so long as they differ in the values they have for the attributes atom:hreflang, xml:lang, or atom:type. I'm not comfortable with either wording. Seems clumsy. meta-question: should the spec even bother asserting t

Re: Comments on format-05

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

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

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

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

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. "If the value of type begins with "text/" or ends

Re: Comments on format-05

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

Re: Comments on format-05

Big +1! On Jan 30, 2005, at 12:34 PM, 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 i

Re: Comments on format-05

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 applicati

Re: PaceXhtmlNamespaceDiv posted

On Jan 30, 2005, at 21:06, Julian Reschke wrote: 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. FWIW, one could

Re: Comments on format-05

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

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

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

Re: Comments on format-05

On Jan 30, 2005, at 9:07 AM, Robert Sayre wrote: Mark Nottingham wrote: My gut feeling is that removing the markup from these elements will make the spec much simpler and easier to implement, without sacrificing many (if any) use cases. If I'm not aware of someone's use case here, I'm sorry and

Re: Comments on format-05

Sam Ruby wrote: Robert Sayre wrote: > >> If I am conflating validity with media types, then so is the XML >> specification. > > > I don't understand that, could you explain? See the XML specification section F.2 [1]. It is quite possible for an XML document to be valid if served with media type

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

On Jan 30, 2005, at 19:06, Anne van Kesteren wrote: In Europe there are lots of different languages. It does not make sense to provide a feed based on language negotiation since feed aggregators do not support that. So how many European sites besides the EU have the resources to provide transla

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I suspect that once people see some examples, objections will surface. It'

Re: Comments on format-05

Robert Sayre wrote: If I am conflating validity with media types, then so is the XML specification. I don't understand that, could you explain? See the XML specification section F.2 [1]. It is quite possible for an XML document to be valid if served with media type application/xml, but for the

Re: URI canonicalization

On 30 Jan 2005, at 7:06 pm, Sam Ruby wrote: Paraphrasing Tim [1] "I'm definitely -1 on losing 3.5.1, the canonicalization warning is a hard-won compromise and seems to cause no-one any pain." We discussed this at extreme length, and no new arguments have been brought forward. Rough consensus d

Re: Comments on format-05

Sam Ruby wrote: I am still confused. Transforming an Atom feed into another format does not result in a valid Atom feed. Right, but it's useful for the tranformation. If I am conflating validity with media types, then so is the XML specification. I don't understand that, could you explain? If t

Re: TEXT mode and whitespace

On Jan 30, 2005, at 9:02 AM, Graham wrote: 3.1.1 "Thus, software MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification." This is horrible and doesn't really tell people at either end anything new. It also needs to directly an

Re: URI canonicalization

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

Re: URI canonicalization

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

Re: Comments on format-05

Robert Sayre wrote: Sam Ruby wrote: Then I am clearly confused. At the moment, the feedvalidator would mark an atom feed as invalid if it were served with the text/plan, application/rss+xml, or application/rdf+xml media types. It accepts as valid text/xml (if the feed is either ASCII or a chars

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I gather that a format-05 compatible feed, thus: ... would become s

Re: URI canonicalization

Paraphrasing Tim [1] "I'm definitely -1 on losing 3.5.1, the canonicalization warning is a hard-won compromise and seems to cause no-one any pain." We discussed this at extreme length, and no new arguments have been brought forward. Rough consensus does not mean absolute consensus. - Sam Ruby

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. Perhap

Re: URI canonicalization

Julian Reschke wrote: 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 supp

Re: PaceXhtmlNamespaceDiv posted

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 t

Re: URI canonicalization

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

Re: Proof-of-concept RDF mapping for Atom

Saturday, January 29, 2005, 11:13:51 AM, you wrote: >> The RDF vocabulary was just constructed ad-hoc - like I said, it is >> just a proof of concept. It uses a separate namespace to Atom and >> defines some new terms, which solves any problems with non-unique >> attributes. > That makes sense

Re: URI canonicalization

Robert Sayre wrote: 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 you do this: http://Example.org/thing http://example.org/thing You cannot c

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

Re: URI canonicalization

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 movin

Re: PaceXhtmlNamespaceDiv posted

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

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: Hmm. How do I do a linkblog with this restriction? I believe a linkblog should always have atom:content which provides some information on the reason why you posted the link or a comment on the link or something similar. -- Anne van Kesteren

Re: PaceXhtmlNamespaceDiv posted

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 gui

Re: PaceOrderSpecAlphabetically

On Jan 30, 2005, at 9:34 AM, Sam Ruby wrote: == Abstract == Order the Element Definitions in the specification alphabetically. +1 -Tim

Re: URI canonicalization

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 agreemen

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. I'll also note that this example is not valid. It does not contain either a summary or content element. Hmm. How do I do a linkblog with this restriction? Robert Sayre

atom:contributor cardinality in -05

> atom:head elements MUST NOT contain more than one atom:contributor element. > atom:entry elements MUST NOT contain more than one atom:contributor element. they look like a copy/pasto, especially since above those lines there is > & atomContributor* e.

Re: Obs on format-05

On Jan 30, 2005, at 9:12 AM, Sam Ruby wrote: I realize that you indicate that you intend to write a Pace on this. Just be aware that earlier drafts of Atom supported multiple content, and a lot of people seemed very motivated to eliminate this. To be fair, it was the original "multipart/alternati

Re: Comments on format-05

Sam Ruby wrote: Then I am clearly confused. At the moment, the feedvalidator would mark an atom feed as invalid if it were served with the text/plan, application/rss+xml, or application/rdf+xml media types. It accepts as valid text/xml (if the feed is either ASCII or a charset is explictly defi

Re: Comments on format-05

Robert Sayre wrote: Sam Ruby wrote: Robert Sayre wrote: * 4.21 The "atom:info" Element -- If it's not considered meaningful for processors, why does there need to be a standard element for it? At the very least, some sort of information about its semantics should be documented. My preference wou

Re: PaceXhtmlNamespaceDiv posted

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

Re: PaceXhtmlNamespaceDiv posted

On Sun, 30 Jan 2005 18:43:18 +0100, Julian Reschke <[EMAIL PROTECTED]> wrote: For the record, I'm opposed to it, too. Same here. 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 expli

Re: URI canonicalization

I suppose I should offer an alternative solution. Two scenarios were given to justify canonicalization: 1) A publisher accidentally uses a different, though very similar, URI for their id. They then apply the canonicalization rules and the error is erased. This will only work if they remember t

Re: Comments on format-05

On 31/1/05 3:47 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> +1, but not just type attributes, also xml:lang variations please. > > -1. An Atom entry is *one* representation and you can link to alternates. > I'm deeply unhappy that this was raised again. We went over and over on > the matter

Re: Comments on format-05

Sam Ruby wrote: Robert Sayre wrote: * 4.21 The "atom:info" Element -- If it's not considered meaningful for processors, why does there need to be a standard element for it? At the very least, some sort of information about its semantics should be documented. My preference would be to drop it.

Re: Comments on format-05

Robert Sayre wrote: * 4.21 The "atom:info" Element -- If it's not considered meaningful for processors, why does there need to be a standard element for it? At the very least, some sort of information about its semantics should be documented. My preference would be to drop it. People use this h

Re: Obs on format-05

Tim Bray wrote: On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote: ** 4.15 The "atom:content" [[[ atom:entry elements MUST contain zero or one atom:content elements. ]]] proposal: I would like this loosened to zero or more (a Pace is forthcoming). I have use cases to ship content about in Irish and

Re: PaceXhtmlNamespaceDiv posted

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

  1   2   >