Re: Why is alternate link a MUST?

2005-04-03 Thread A. Pagaltzis
* Sam Ruby [EMAIL PROTECTED] [2005-04-03 04:30]: Every version of RSS has required this link. I've *never* heard anybody complain about this in the context of any version of RSS. It puzzles the bejeebers out of me why this issue is only brought up in the context of Atom. My guess is that

Re: Spaces supports slash:comments. Result = Duplicates Galore!

2005-04-07 Thread A. Pagaltzis
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-07 22:55]: F.ex, entries maliciously published with someone elses entry ID will not actually constitute a DOS attack for consumers whose aggregator maintains a history of previously seen versions of an entry. Sorry, wrong thread. I have been

Re: One reason we have duplicates entries is that we have duplicate feeds...

2005-04-07 Thread A. Pagaltzis
* Bob Wyman [EMAIL PROTECTED] [2005-04-07 22:40]: A. Pagaltzis wrote: But it breaks down for the aggregate feeds published by third parties. If look at more convoluted examples, it fast turns into web of trust territory... You are correct -- with one caveat. If entries are signed, Yes

Re: PaceCoConstraintsAreBad

2005-04-09 Thread A. Pagaltzis
* Sam Ruby [EMAIL PROTECTED] [2005-04-09 22:30]: What compelling use case would enabling the omission of non-remote, textual content - i.e., not merely providing a zero length content, but the outright omission of same - enable? I have no opinion either way (not that it would have much

Re: PaceCoConstraintsAreBad

2005-04-10 Thread A. Pagaltzis
* James Aylett [EMAIL PROTECTED] [2005-04-10 11:55]: On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote: * the atom:entry contains an atom:content that has a src attribute (and is thus empty). FWIW, for clarity I would favour: '... has a src attribute (and is thus itself

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

2005-04-13 Thread A. Pagaltzis
* Henri Sivonen [EMAIL PROTECTED] [2005-04-13 08:25]: On Apr 13, 2005, at 01:02, Robert Sayre wrote: [XHTML transitional reference] Instead of saying XHTML it would be clearer to say XHTML 1.x or defining it in terms of the XHTML 1.x namespace URI. He already did, no? Regards, --

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

2005-04-13 Thread A. Pagaltzis
* Asbjrn Ulsberg [EMAIL PROTECTED] [2005-04-13 02:35]: Or, we should restrict the allowed XHTML versions in the specification to just include 1.x. That leads to different problems, though, since people would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are totally

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

2005-04-13 Thread A. Pagaltzis
* David Powell [EMAIL PROTECTED] [2005-04-13 21:50]: I agree that the Atom RFC shouldn't be a moving target. How about if we: Make an IANA registry of Atom Text Types, requiring some level of RFC to create new ones. Put text, html, and xhtml in the registry, and specify that

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

2005-04-15 Thread A. Pagaltzis
* Antone Roundy [EMAIL PROTECTED] [2005-04-15 00:10]: feed xmlns=our namespace URI ... atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's namespace URI divThis is XHTML content,br / and the default namespace is XHTML's./div /atom:content I like this. A lot. * Asbjrn

Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

2005-04-15 Thread A. Pagaltzis
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-15 20:20]: * Antone Roundy [EMAIL PROTECTED] [2005-04-15 00:10]: feed xmlns=our namespace URI ... atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's namespace URI divThis is XHTML content,br / and the default namespace

Re: How should this be rendered?

2005-04-16 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-04-16 21:45]: Atom Processors MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification. MAY or MAY NOT. There's no right answer in there right now. Would @xml:space be applicable if I

Re: xml:base and html rendering

2005-04-21 Thread A. Pagaltzis
* Bill de hra [EMAIL PROTECTED] [2005-04-21 17:55]: My point (which still stands afaict) is that this is a structural matter, to do with bleed from the container in the content and that we've solved it with a different approach altogether for namespaces than what's being suggested for

Re: PaceOptionalSummary

2005-04-26 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-04-26 23:00]: So your app sends me an Atom document that looks like this: entry idwhetever/id titleSo Caleb is Lindsey's father/title /entry What does this mean? Thats invalid, since its missing both an atom:content as well as an atom:[EMAIL

Re: PaceOptionalSummary

2005-04-26 Thread A. Pagaltzis
* Tim Bray [EMAIL PROTECTED] [2005-04-25 20:35]: I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary So far I havent seen a cogent explanation of the significant semantics offered by an empty atom:summary inside an otherwise valid

Re: PaceOptionalSummary

2005-04-27 Thread A. Pagaltzis
* Sam Ruby [EMAIL PROTECTED] [2005-04-27 12:45]: So.. can we agree on SHOULD? +1. My previous tentative +1 for MAY is hereby withdrawn. Regards, -- Aristotle

Re: PaceExplainDuplicateIds

2005-05-01 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-04-30 22:15]: Remove the bullet point that reads {{{ atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values. }}} Add a paragraph after the list that reads {{{ Atom Processors use the atom:id element found in Atom

Re: PaceExplainDuplicateIds

2005-05-01 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-01 18:45]: perhaps we need to explain the concept of 'entries' (as resources), as distinct from entrys (as representations), and explain that 'entries' must have unique IDs, and that the atom:id element of any atom:entry ties it back to the 'entry'

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

2005-05-05 Thread A. Pagaltzis
* Thomas Broyer [EMAIL PROTECTED] [2005-05-03 19:35]: This means type=text content is a single paragraph of text. If you need paragraphs, lists or any other structural formatting, you have to use type=html or type=xhtml with the appropriate content. Or type=text/plain, Id assume? Regards,

Re: Atom 1.0?

2005-05-10 Thread A. Pagaltzis
* Tim Bray [EMAIL PROTECTED] [2005-05-10 04:40]: We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3 there'll be no actual spec-based reason to call our product Atom 1.0. But, we could just go ahead and do it anyhow. +1 for Atom 1.0 since a

Re: PaceOptionalSummary

2005-05-10 Thread A. Pagaltzis
* Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? Regards, -- Aristotle

Re: Atom 1.0?

2005-05-11 Thread A. Pagaltzis
* Bill de hra [EMAIL PROTECTED] [2005-05-11 17:05]: ARSS, short for Atom RSS. The marketing possibilities are endless. How about Atom Syndication Standard? I guess the Firefox crowd can then resurrect the non-Wifi looking autodiscovery icon. Regards, -- Aristotle

Re: Fetch Me A Rock

2005-05-13 Thread A. Pagaltzis
* David Nesting [EMAIL PROTECTED] [2005-05-13 15:25]: It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that

Re: PaceContentAndSummaryDistinct

2005-05-14 Thread A. Pagaltzis
On Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote: After seeing 'in the wild' what I consider badly-formed Atom feeds, where both the atom:summary and atom:content contain identical abbreviated entry text, I realised that the spec does not make this clear.

Re: PaceContentAndSummaryDistinct

2005-05-15 Thread A. Pagaltzis
* Thomas Broyer [EMAIL PROTECTED] [2005-05-15 17:10]: A. Pagaltzis wrote: The atom:content element either contains or links to the full content of the entry. An atom:entry containing an atom:content element MUST be a complete representation of the entry. If the atom:entry

Re: PaceContentAndSummaryDistinct

2005-05-15 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-05-16 01:10]: Let's say I put the first sentence of each post in atom:summary. What happens when I post a one sentence entry? Then you must not put it in the summary. And this is my opinion independent of the pace. An even half-way intelligent user agent would

Re: PaceContentAndSummaryDistinct

2005-05-15 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-05-16 01:15]: An atom:entry MUST NOT have both an atom:content and an atom:summary element with identical content. -1 It might solve this exact problem, but in the general case it makes no sense. Besides my point in the other mail, I wanted to

Re: PaceContentAndSummaryDistinct

2005-05-15 Thread A. Pagaltzis
* James Tauber [EMAIL PROTECTED] [2005-05-16 05:45]: I believe it is reasonable to: 1. include a summary element in my full-content feed in addition to the content element; and Absolutely it is. F.ex, user agents could provide the summary in addition to the title of an entry in a feed

Re: Consensus call on last raft of issues

2005-05-18 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-05-18 23:15]: On 18 May 2005, at 9:36 pm, Robert Sayre wrote: Regardless of how an associated application will handle entries with no atom:summary element, all Atom Processors MUST NOT fail to process Atom entries simply because they contain no atom:summary

Re: multiple atom:author elements?

2005-05-20 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 17:50]: contributor category term=Author/ nameBarnable Foo/name .../ /contributor +1 Very elegant. As for the inheritance problem this does bring up: the current spec implicitly defines that no

Re: multiple atom:author elements?

2005-05-20 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-05-20 20:30]: Well unless we make category/term machine readable, we might as well just have a plain text blob. But we already did that. Theres an option @scheme attribute for atom:category. Thats part of the elegance of this approach. Regards, -- Aristotle

Re: multiple atom:author elements?

2005-05-20 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 20:10]: On 21/5/05 3:41 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: However, it does pose a problem of default semantics. Do we define particular categories in the spec? If we dont, do we define a default category to be assumed in absence

Re: extension elements anywhere?

2005-05-20 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 19:55]: 6.4Extension Elements Atom allows foreign markup anywhere in an Atom document. does this mean this is allowed: title type=texthello world!foo:evil:-)/foo:evil/title You request adding except where they are explicitly forbidden

Re: Fetch me an author. Now, fetch me another author.

2005-05-21 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), +1, calling it author when that sort of usage is expected and encouraged is a lie. and some mechanism introduced to indicate

Re: Fetch me an author. Now, fetch me another author.

2005-05-21 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]: At this stage, changing the spec to suit religious preferences would be extremely arrogant. Please stop talking to people about process bullshit at one occasion and turning around to chide others for at this stage at the next. Regards, --

Re: I wanna go home

2005-05-21 Thread A. Pagaltzis
* Antone Roundy [EMAIL PROTECTED] [2005-05-22 05:25]: Multiple authors: * Allow multiple atom:author elements per feed/entry * Keep atom:contributor * Leave byline or ordering of authors to an extension for those who need it +1 Multiple instances of an entry in a feed document * Allow it

Re: Fetch me an author. Now, fetch me another author.

2005-05-21 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 21:25]: On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]: At this stage, changing the spec to suit religious preferences would be extremely arrogant. Please stop talking to people about

Re: updated and modified yet again

2005-05-21 Thread A. Pagaltzis
* Tim Bray [EMAIL PROTECTED] [2005-05-22 04:50]: I do not agree in the slightest that atom:modified is any more useful than atom:updated for these purposes. The only distinction between modified and updated is that there might be changes, not considered significant by the publisher, which

Re: How is Atom superior to RSS?

2005-05-22 Thread A. Pagaltzis
* Bob Wyman [EMAIL PROTECTED] [2005-05-22 08:05]: I'll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them. I think the main attractions are pretty clear: Thoroughly specified

Re: some small comments on 08

2005-05-22 Thread A. Pagaltzis
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]: * 4.1.3.1 The type attribute Can I circumvent the DIV element by using the media type of XHTML? (I really dislike this combined construct by the way.) I used to find it extremely horrible. Now Im not sure. There is some symmetry

Re: some small comments on 08

2005-05-22 Thread A. Pagaltzis
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]: * 3.1.1.3 XHTML I would like to see valid XHTML more clearly defined. There are a lot of different XHTML versions I know of and some might not include a DIV element at all... You have XHTML 1 (in three versions), XHTML 1.1, XHTML

Re: Author and contributor

2005-05-22 Thread A. Pagaltzis
* Tim Bray [EMAIL PROTECTED] [2005-05-23 07:00]: Unfortunately, among those who want to change the current setup, we do not observe consensus on the subject of what to change them to. Near as we can tell, people want to make atom:author plural, some want to nuke atom:contributor and others

Re: Author and contributor

2005-05-23 Thread A. Pagaltzis
* David Powell [EMAIL PROTECTED] [2005-05-23 09:45]: make atom:author plural +1 in principle... But has anyone addressed how this will inherit - will atom:entry/atom:author merge with the set of authors defined in atom:feed/atom:author or will it replace them? Merging is easy to

Re: some small comments on 08

2005-05-23 Thread A. Pagaltzis
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 09:05]: Robert Sayre wrote: For white-space significance text I need to use 'html' or 'xhtml' instead using PRE or xhtml:pre? I don't understand what you're saying here, but I'm pretty sure every possible whitespace issue has been debated

Re: some small comments on 08

2005-05-23 Thread A. Pagaltzis
* Thomas Broyer [EMAIL PROTECTED] [2005-05-23 10:50]: A. Pagaltzis wrote: There is some symmetry here: with @type=xml, you have to Which @type=xml? Did you mean @type=text/xml? Sorry, I meant any XML media type. enclose a full XML document, which will always have a root element

Re: some small comments on 08

2005-05-23 Thread A. Pagaltzis
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 10:35]: A. Pagaltzis wrote: Last I asked, I understood that whitespace would be preserved if you supply 'text/plain' content; @type='text' is more like inline text in an XML document (or in HTML). Maybe the spec could be more explicit about

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-05-23 12:50]: http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor +1 Regards, -- Aristotle

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. No need to punch it down here again separately. Regards, -- Aristotle

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 14:45]: On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:15]: I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by

Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread A. Pagaltzis
* Dan Brickley [EMAIL PROTECTED] [2005-05-23 16:40]: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Doesnt seem to me like there should be any

Re: inheritance issues (was: Author and contributor)

2005-05-23 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]: Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the

Re: atom:type, xsl:output

2005-05-24 Thread A. Pagaltzis
* James Cerra [EMAIL PROTECTED] [2005-05-24 06:35]: XML 1.1 Not supported. I'm confused. There is nothing inherent in the spec that prevents XML 1.1 or any future versions from being supported. And why introduce incompatibilities in atom:content that also bork with arbitrary XML

Re: inheritance issues (was: Author and contributor)

2005-05-24 Thread A. Pagaltzis
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 09:05]: a) feed: author: A contributor: B entry: no author not contributor b) feed: author: A contributor: B entry: author: C c) feed: author: A contributor: B entry: contributor: C d) feed:

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

2005-05-24 Thread A. Pagaltzis
* Karl Dubost [EMAIL PROTECTED] [2005-05-24 20:05]: It means that all XSLTs, Web hosting services, etc can NOT claim conformance to Atom. :) Yes they can. no for the reason I gave and no because there's no way to claim conformance to the spec. They are plenty marketing department

Re: inheritance issues (was: Author and contributor)

2005-05-24 Thread A. Pagaltzis
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 15:15]: A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering

Re: atom:type, xsl:output

2005-05-26 Thread A. Pagaltzis
* James Cerra [EMAIL PROTECTED] [2005-05-26 05:35]: Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. Then there are example XML documents (i.e. for tutorials) that sometimes require comments be preserved. Entities can be

Re: atom:type, xsl:output

2005-05-26 Thread A. Pagaltzis
* Henri Sivonen [EMAIL PROTECTED] [2005-05-26 10:20]: On May 26, 2005, at 06:23, James Cerra wrote: Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. I am not familiar with that. What purpose exactly? Why should Atom support it?

Re: atom, xslt processors (Re: atom:type, xsl:output)

2005-05-28 Thread A. Pagaltzis
* James Cerra [EMAIL PROTECTED] [2005-05-28 04:00]: Nothing prevents anyone from writing a generator or pre- or postprocessor for Atom documents to cater to the needs of their particular brand of broken software. Wrangling that particular piece of broken software however is their job; not

Re: some xmlns:atom tomfoolery

2005-05-28 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-05-28 11:00]: An Atom Entry can have XML content, right... Consider this example: Entirely legal, but who wants to bet the feed validator throws a fit ;-) Most aggregators will probably ignore the content, and likely not even do anything useful with

Re: atom:type, xsl:output

2005-05-30 Thread A. Pagaltzis
* James Cerra [EMAIL PROTECTED] [2005-05-30 03:20]: Depending on an entity reference and not being able to accept the straight replacement text is just wrong. I agree. I'm just bringing up possible incompatibilities for debate! I don't think that's an incompatibility that

Re: OpenSearch RSS

2005-05-31 Thread A. Pagaltzis
* James Aylett [EMAIL PROTECTED] [2005-05-31 11:10]: It does limit things (at least by draft-ietf-atompub-format-08) in that if I aggregate two search feeds into one and they have search results for the same site, either I have to drop one of them or I have to rewrite all the atom:id values

Re: feed or entry

2005-06-17 Thread A. Pagaltzis
into the atom:feed document using a stylesheet? This is how my own blog works. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-17 Thread A. Pagaltzis
, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread A. Pagaltzis
?) for that sort of thing Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-19 Thread A. Pagaltzis
to do with multipart/*, then great. But if it doesnt, then the Atom processor certainly wont care one way or the other. Funnily enough, thats exactly the same treatment that any other known or unknown MIME type receives. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-19 Thread A. Pagaltzis
* Graham [EMAIL PROTECTED] [2005-06-18 21:50]: The better way to do this is to use atom:link rel=alternate to reference the messages. Is there any verbiage that would preclude a data: URI with a multipart payload in atom:link? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: The atom:uri element

2005-06-27 Thread A. Pagaltzis
it with a @link attribute on the Name Construct’s root element. But, as mentioned, the spec, modulo bugs, is a done deal at this point. And if the atom:uri element’s naming really turns out to be the biggest wart in the spec, then I’ll gladly suffer it. :-) Regards, -- Aristotle Pagaltzis // http

Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

2005-06-29 Thread A. Pagaltzis
containing all entries, and use RFC3229+feed to return partial versions of it; as far as I can tell, this is a use case which your draft does *NOT* allow. Is that so? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Clearing a discuss vote on the Atom format

2005-07-01 Thread A. Pagaltzis
Documents MUST use Canonical XML by default; they MAY use other canonicalizations at user request. I agree, but I think the second wording is confusing. It doesn’t actually say anything different from the first wording, even though it seems to imply more. Regards, -- Aristotle Pagaltzis // http

Re: Clearing a discuss vote on the Atom format

2005-07-01 Thread A. Pagaltzis
be Atom Processors that sign Atom Documents MUST support the use of Canonical XML. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

2005-07-01 Thread A. Pagaltzis
which inform the client how to request the entirety of the feed – maybe Resource-Initial-ETag or something like that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Clearing a discuss vote on the Atom format

2005-07-01 Thread A. Pagaltzis
* Eric Scheid [EMAIL PROTECTED] [2005-07-01 11:25]: On 1/7/05 7:01 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Atom Processors that sign Atom Documents MUST support the use of Canonical XML. what about Atom Processors that are not signing stuff, but is instead reading/validating

Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread A. Pagaltzis
in any way, it just explicates ramifications of the spec as it already stands,) it would be a very worthwhile addition. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Roll-up of proposed changes to atompub-format section 5

2005-07-06 Thread A. Pagaltzis
* Paul Hoffman [EMAIL PROTECTED] [2005-07-06 01:20]: Does anyone object to the following exact wording being added right after the new paragraph on canonicalizing: Not me. +1 to the addition. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-12 Thread A. Pagaltzis
think defining an extension element as outlined above and providing a unified feed of comments for all entries makes the most sense. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Old application/atom+xml issues

2005-07-12 Thread A. Pagaltzis
before aggregators and producers all support the new spec in unison. So in light of these and Robert’s arguments, there’s no apparent reason to attempt to interoperate. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-12 Thread A. Pagaltzis
? An alternative might be to define a format for this need that used Atom elements but had minimalized cardinality requirements. That’s a really drastic measure for such negligible benefit. One Format To Rule Them All, as far as I’m concerned. Regards, -- Aristotle Pagaltzis // http

Re: More while we're waiting discussion

2005-07-12 Thread A. Pagaltzis
liking this a lot. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-12 Thread A. Pagaltzis
feed which the particular aggregator does not subscribe. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-13 Thread A. Pagaltzis
of the change might be considered too major. Unless maybe it’s argued that this was what the spec said all along, and this change therefore is just clarification? I don’t know. Colour me lost.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-13 Thread A. Pagaltzis
remains one and the same: the aggregator must somehow be able to tell that some of the linked feeds are highly relevant, whereas others are merely of tangential interest. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-13 Thread A. Pagaltzis
the waters semantically such that loosely related extraneous feeds cannot be distinguished from highly relevant ones – without offering any actaul simplicity at all in return. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-13 Thread A. Pagaltzis
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-13 08:11]: Obviously, my own vote is that it’s fine as is: I see no reason that dictates that atom:link must point to a concrete Web resource, rather than just an abstract one – neither conceptually/semantically nor in terms of consequences

Re: More while we're waiting discussion

2005-07-13 Thread A. Pagaltzis
) would be the logical choice for this particular use case, as they offer defined semantics for attaching metadata directly to an entry. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: HTTP Accept Headers for Atom V1.0?

2005-07-15 Thread A. Pagaltzis
for Atom 0.3. If people do give you that in return for a request for Atom 1.0, well, no standard is going to be much help – the failure is at their end and you simply can’t do anything about that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: FormatTests

2005-07-16 Thread A. Pagaltzis
as they may be –, but advises that the generation of new IDs should be adjusted. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Evangelism, etc.

2005-07-16 Thread A. Pagaltzis
? :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Media extensions

2005-07-16 Thread A. Pagaltzis
solely around RSS since there wouldn’t have been any Atom format to think about. We should be glad that the spec was pushed through at the final stages; a tip of the hat to the WG chairs and members who insisted on making haste with a Good Enough text. Regards, -- Aristotle Pagaltzis // http

Re: Media extensions

2005-07-16 Thread A. Pagaltzis
popular podcasts are probably RSS 2.0, but I would be surprised if a number of podcasts aren’t provided in both formats. I don’t know much about that, though, as I haven’t had much interest in the phenomenon itself. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: [rss-media] Re: Media extensions

2005-07-16 Thread A. Pagaltzis
aren’t likely to officially bless any such effort, instead considering it the team’s responsibility to figure things out, much like they seem to be doing with Safari and its standards compliance. The cultures at the two companies obviously differ. Regards, -- Aristotle Pagaltzis // http

Re: More while we're waiting discussion

2005-07-16 Thread A. Pagaltzis
that do that. The browsers which know render feeds in a meaningful fashion by themselves (Safari, Firefox+extension) do allow that. Unsurprising, really, as feeds have yet to emerge into a lot of areas outside weblogs or similarly structured content outlets. Regards, -- Aristotle Pagaltzis

Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt

2005-07-16 Thread A. Pagaltzis
, how can RFC3229+feed provide subsets where one end isn't tied to the most recent entry? It can’t. Is there a need for that beyond a minor overhead of redundancy? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-16 Thread A. Pagaltzis
, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: More while we're waiting discussion

2005-07-17 Thread A. Pagaltzis
Ugh, I was as clear as mud. * A. Pagaltzis [EMAIL PROTECTED] [2005-07-17 06:20]: It would make more sense to me to say that a particular type of @rel value always expects a dereferencable URI or never expects on. “in-reply-to” would be in the latter category. I can see the value in having

Re: FormatTests

2005-07-17 Thread A. Pagaltzis
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-16 18:00]: I suppose the message you got was http://www.feedvalidator.org/docs/warning/ObscureEncoding.html ? Err, of course not, but now I’m not sure that http://www.feedvalidator.org/docs/warning/NonCanonicalURI.html is new or was simply changed

Re: Atom 1.0 xml:base/URI funnies

2005-07-18 Thread A. Pagaltzis
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 01:25]: A. Pagaltzis wrote: He is correct, Tim. The base URI means “the URL where this document was found,” not “the prefix for any enclosed relative links.” I don’t see how RFC3986 can be read any other way. I am correct ;), but your

Re: Feed History -02

2005-07-18 Thread A. Pagaltzis
. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom 1.0 xml:base/URI funnies

2005-07-18 Thread A. Pagaltzis
by the fact that some issues may never even have had a clear rationale. See f.ex. our current debate about whether atom:link/@href was meant to always be dereferencable or may be any URI at all, abstract or not.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom 1.0 xml:base/URI funnies

2005-07-19 Thread A. Pagaltzis
, -- Aristotle Pagaltzis // http://plasmasturm.org/

  1   2   3   4   >