Re: RSS extensibility

2005-01-07 Thread Antone Roundy
On Friday, January 7, 2005, at 01:32 PM, Danny Ayers wrote: If I propose an extension, e.g. embargoDate, and I want anyone to use it, then I'm going to have to specify how it works. E.g. prism:embargoDate can appear as a child of atom:entry and it gives the embargo date for the entry... ...

Re: Enclosure count

2005-01-07 Thread Antone Roundy
On Friday, January 7, 2005, at 01:59 PM, David Jacobs wrote: RSS 2.0 DOES have a one enclosure per entry restriction, so we're breaking RSS2 compatibility. Why wouldn't multiple enclosures be multiple posts? Multiple enclosures per entry would make it impossible to translate some Atom feeds to

Re: Atom extensibility

2005-01-07 Thread Antone Roundy
Let me see if I can correctly restate the following in language I'm familiar with--let me know whether I've got this right or not: On Friday, January 7, 2005, at 03:38 PM, David Powell wrote: I'd say that the most useful basic features of RDF are: 1) Property names are namespaced for

Re: Signatures in feeds of Aggregated Entry Documents

2005-01-10 Thread Antone Roundy
On Sunday, January 9, 2005, at 03:18 AM, Eric Scheid wrote: sidebar: does the signature technology we use for the atom format allow us to state that certain child elements are not to be included in the signature algorithm. I'm thinking of something along the lines of the following... feed

Re: PaceFeedRecursive

2005-01-10 Thread Antone Roundy
On Sunday, January 9, 2005, at 05:36 PM, Roy T. Fielding wrote: I just created a starting point for a proposal on making the feed element recursive, eliminating the need for RDF syntax, atom:head, and a bunch of things proposed in other paces regarding aggregators and digital signatures.

Re: Questions about -04

2005-01-12 Thread Antone Roundy
On Wednesday, January 12, 2005, at 09:57 AM, Robert Sayre wrote: 3. 4.2.2 says atom:head elements MUST NOT contain more than one atom:link element with a rel attribute value of alternate that has the same type attribute value. What if the atom:link elments have different hreflang values?

PaceMinimalEntryVersioning

2005-01-12 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceMinimalEntryVersioning Multiple instances or versions of the same entry MAY appear in a feed, index, or archive. I'm in favor of this--it's easy enough to imagine uses for it (like a feed showing the history of a particular entry). Consumers MAY choose

PaceMustUnderstandElement

2005-01-12 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement Any Atom document MAY contain a single atom:must-understand element, which, if it appears, MUST be the first child element of the document element. I think we need to add language stating that aggregators aggregating entries

PacePropertyDesign

2005-01-12 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PacePropertyDesign * Simple The content of the element MUST be CDATA, and have no attributes. Perhaps character data instead of CDATA would be better, as a quick reading might be taken to imply that the content must be in ![CDATA[ ]]. * RDF Resource

Re: Questions about -04

2005-01-12 Thread Antone Roundy
On Wednesday, January 12, 2005, at 04:53 PM, Sam Ruby wrote: Graham wrote: On 12 Jan 2005, at 9:54 pm, Sam Ruby wrote: 2. Why MUST a feed point to an alternate version. What if the feed is all I publish? Deja vu: http://www.imc.org/atom-syntax/mail-archive/msg08836.html I'm -1 on removing

Re: Posted PaceExtensionConstruct

2005-01-12 Thread Antone Roundy
On Wednesday, January 12, 2005, at 05:27 PM, David Powell wrote: Wednesday, January 12, 2005, 10:51:58 PM, you wrote: The root element of a Structured Extension construct MAY have attributes, it MAY contain well-formed XML content, or it MAY be empty. It took me a minute to realize that the

Re: PaceMustUnderstandElement

2005-01-13 Thread Antone Roundy
On Thursday, January 13, 2005, at 01:51 PM, Graham wrote: On 13 Jan 2005, at 6:36 pm, Tim Bray wrote: The objections to this fall into two forms: 1. We don't have prior art in the syndication space that proves this is needed. 2. This is someone else's problem, e.g. SOAP 3. We don't need it

Re: PaceMustUnderstandElement

2005-01-13 Thread Antone Roundy
On Thursday, January 13, 2005, at 03:34 PM, Graham wrote: The main problem ince a possibly large percentage won't implement it, using mustUnderstand in a feed doesn't prevent whatever dire consequences there might be of ignoring the elements that must be understood, which makes the proposed

Re: PaceMustUnderstandElement

2005-01-13 Thread Antone Roundy
On Thursday, January 13, 2005, at 03:29 PM, Roger B. wrote: But how likely is it that the problems will outweigh the benefits? Antone: Extremely, in my opinion. A big -1 on this one. All it will take is an A-lister or three on a mission to essentially force every general-use client developer to

Re: PaceSyntaxGuidelines status

2005-01-24 Thread Antone Roundy
7.2 Common element usage The following actual elements should only be used in the ways specified below. * link: Purposes of link elements are specified by a list of legal values for link/@rel, and we are considering allowing extensions to specify additional values. If the external

Re: PaceFeedState status

2005-01-24 Thread Antone Roundy
On Monday, January 24, 2005, at 06:09 PM, Joe Gregorio wrote: I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on //atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage that makes demands on clients, for example, Atom consumers MUST warn users when they do not

Re: PacePersonLinks status

2005-01-24 Thread Antone Roundy
On Monday, January 24, 2005, at 06:25 PM, Eric Scheid wrote: On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: Has failed to get anywhere near enough support to call rough consensus in previous go-arounds. -Tim was that failure of consensus due to

Re: PaceEnclosuresAndPix status

2005-01-24 Thread Antone Roundy
On Monday, January 24, 2005, at 05:18 PM, Tim Bray wrote: If there were no further discussion: Got no -1's, seems useful, needed for feature parity with RSS2, will likely go in absent some objections. -Tim -0.7. Turns link into a kitchen sink by using it to point to things that are intended

Re: PaceAttributesNamespace is *not* about syntax!

2005-01-26 Thread Antone Roundy
On Wednesday, January 26, 2005, at 07:03 AM, Sam Ruby wrote: Let's assume that there will be a non-normative appendix which describes the mapping of the Atom/XML syntax to RDF triples (possibly via a mapping to RDF/XML or possibly directly). Clearly, such an appendix would need to define a

Re: PaceEnclosuresAndPix status

2005-01-27 Thread Antone Roundy
On Wednesday, January 26, 2005, at 10:40 PM, Eric Scheid wrote: so, icon ... or favicon. I prefer the latter. I prefer the former. favicon = favorites icon. I think favorites is a bad name for bookmarks--a person's reason for bookmarking something (or in the case of Atom, subscribing to a

Mandatory method of specifying XHTML namespace?

2005-01-27 Thread Antone Roundy
Given how common it is even for us, when posting examples of content type=XHTML without declaring the XHTML namespace, might it be a good idea to specify a mandatory method of declaring the XHTML namespace to ensure that implementors don't forget? I realize that it could be done multiple

Re: PaceXhtmlNamespaceDiv posted

2005-01-27 Thread Antone Roundy
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote: On Jan 27, 2005, at 22:30, Antone Roundy wrote: I'm not in favor of mandating restrictions, because there are probably legitimate uses for anything we might try to protect people against. The namespace div places restrictions

Re: URI canonicalization

2005-01-31 Thread Antone Roundy
On Sunday, January 30, 2005, at 05:43 PM, 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

Re: Obs on format-05

2005-01-31 Thread Antone Roundy
On Sunday, January 30, 2005, at 10:25 AM, Tim Bray wrote: ** @type ** The passages in 3.1.1 and 4.15.1 and 4.6.3 around @type are not consistent. In 3.1.1 media types are not an option: [[[ Note that MIME media types [RFC2045] are not acceptable values for the type attribute. ]]] in 4.15.1

Re: Comments on format-05

2005-01-31 Thread Antone Roundy
On Sunday, January 30, 2005, at 10:49 AM, Eric Scheid wrote: 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

PaceAggregationDocument posted

2005-01-31 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceAggregationDocument PaceAggregationDocument is an alternative to PaceFeedRecursive (and was largely cloned from PaceFeedRecursive). Both replace head-in-entry as a way to carry an entry's original context with it when aggregating feeds. The primary

Re: PaceAggregationDocument posted

2005-01-31 Thread Antone Roundy
On Monday, January 31, 2005, at 03:23 PM, Antone Roundy wrote: 1) PaceFeedRecursive enables aggregation by allowing the document element feed to contain other feeds (but those feeds may not contain yet other feeds). Correction: PaceFeedRecursive doesn't contain any language limiting the depth

Re: PaceAggregationDocument posted

2005-01-31 Thread Antone Roundy
On Monday, January 31, 2005, at 08:51 PM, Robert Sayre wrote: Graham wrote: Both proposals suck equally. HeadInEntry is surprisingly elegant when you get to thinking about it. My preferences are as follows: 1.) PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and atom:content 2.) RDF

Re: Principled Reasoning. was: PaceAggregationDocument posted

2005-02-01 Thread Antone Roundy
On Tuesday, February 1, 2005, at 06:08 AM, Henry Story wrote: ... Without taking the trouble to purchase and read the book you pointed to, here is my reasoning: Antone Roundy wrote: My preferences: +1: Current draft or PaceAggregationDocument (with or without atom:feed/atom:head

Re: URI canonicalization

2005-02-01 Thread Antone Roundy
On Monday, January 31, 2005, at 10:57 PM, Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but

Re: PaceFormatSecurity to be updated?

2005-02-02 Thread Antone Roundy
On Wednesday, February 2, 2005, at 01:31 AM, Robert Sayre wrote: Every Atom Processor should carefully consider their handling of every type of element when processing incoming (X)HTML in Atom documents. ...and might wish to remove all unrecognized elements.

Re: tagline - subtitle

2005-02-02 Thread Antone Roundy
On Wednesday, February 2, 2005, at 09:49 AM, Henry Story wrote: Why not go one step further in generality and call the tagline the summary? Then we will be closer to the point I had been making in PaceEntriesAllTheWayDown2, and one step closer to showing that a Feed head is the same structure

PaceIconAndImage - icon aspect ratio

2005-02-02 Thread Antone Roundy
The atom:icon element's content is a URI which identifies an image which provides iconic visual identification for a feed. The image SHOULD have an aspect ratio of one (horizontal) to one (vertical), and should be suitable for presentation in small size. Is there any reason why the aspect ratio

Re: Format spec vs Protocol spec

2005-02-02 Thread Antone Roundy
On Wednesday, February 2, 2005, at 11:56 AM, Walter Underwood wrote: We are assuming that Atom will need extensions for new applications, but it should not need extensions for editing blog entries. I'd have to disagree. I don't think it inappropriate for elements that exist for use by the

Re: Format spec vs Protocol spec

2005-02-02 Thread Antone Roundy
On Wednesday, February 2, 2005, at 12:33 PM, Walter Underwood wrote: --On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy [EMAIL PROTECTED] wrote: On Wednesday, February 2, 2005, at 11:56 AM, Walter Underwood wrote: We are assuming that Atom will need extensions for new

Re: Principled Reasoning. was: PaceAggregationDocument posted

2005-02-02 Thread Antone Roundy
On Tuesday, February 1, 2005, at 01:05 PM, Antone Roundy wrote: -2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and atom:content Potentially unlimited recursion, and potentially significantly more connections required to get a feed. This may not be a big deal to applications

PaceAggregationDocument updated

2005-02-02 Thread Antone Roundy
I added the requirement for atom:aggregation to have atom:head as its first child element. Having heard no comments on the subject of whether or not it should be there, I thought about it a little and decided it should. I also decided not to do away with atom:head and move its children back

PaceCommentFeeds posted

2005-02-03 Thread Antone Roundy
This doesn't seem to have made it when I sent it last night, so here it is again: An alternative to PaceEntriesElement - doesn't address all of the same issues, but combined with PaceAggregationDocument, would address a number of them. http://www.intertwingly.net/wiki/pie/PaceCommentFeeds

Re: PaceCollection

2005-02-03 Thread Antone Roundy
On Wednesday, February 2, 2005, at 11:55 PM, James Snell wrote: In any case, we're talking about something as simple as the name of a single element. I just don't see any real technical value in changing it's name. It doesn't make processing any easier. It doesn't change any of the functional

Re: PaceRemoveVersionAttr

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote: - It seems very likely to me that Atom will evolve over time. - For some applications, changing the namespace name with every version is entirely impractical. Atom may or may not be in this category. Do feeds become legacy? Are

Re: Organization Use Cases

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 07:54 PM, Robert Sayre wrote: 2.) A Blog w/ comments, where on post serves as the root of a collection of other posts. HTML-- http://www.livejournal.com/users/giant_moose/ Atom 0.3, no indication of comments--

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote: Figured I would formalize what I've been evangelizing the past couple of days. http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec The only reason why I'm not in favor of this (in fact, it occurred to me a little

Re: On organization and abstraction

2005-02-03 Thread Antone Roundy
On Thursday, February 3, 2005, at 09:08 PM, Bob Wyman wrote: I see two non-compelling benefits to PaceAggregationDocument over PaceHeadInEntry: 1. In the case where a feed will contain more than one entry from a foreign feed, you only have to include the atom:head data once. Thus, there would

PaceAggregationDocument2 posted

2005-02-04 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceAggregationDocument2 Simplified version of PaceAggregationDocument: adds an aggregation document element without attempting to redefine all Atom elements as either metadata or containers in order to make the impact on the current specification easier to

Re: Don't mess with HeadInEntry!

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 01:29 AM, Bob Wyman wrote: 4. We've been talking about HeadInEntry ever since I proposed it back in June at the Atom Community meeting. On numerous occasions, the group as a whole has rejected the various feed of feed proposals as overly complex and unnecessary.

Re: PaceIconAndImage

2005-02-04 Thread Antone Roundy
On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote: Also, why limit this to feed/head, and not entry? If we ARE going to limit images to feeds, then please, let's change the name to logo. If it were logo, I'd agree it doesn't belong in entry.

Re: PaceIconAndImage

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 12:37 PM, Robert Sayre wrote: Antone Roundy wrote: Let me restate this in a way that might lead to action: I have a sneaking suspicion that we're not going to get consensus on allowing image and/or icon in entry. If that's the case, would anyone object to me

Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 02:05 PM, Tim Bray wrote: On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote: That means that you're not allowed to sue the same atom:id in any two entries, ever. I don't read it that way, although I understand how you might infer that; there's too much wiggle

Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote: An Identity construct is an element whose content conveys an unchanging identifier which MUST be universally unique within Atom Documents to the set of all versions and instantiations of the resource that the construct's parent

Re: Posted PaceEntryOrder (was Entry order)

2005-02-05 Thread Antone Roundy
On Saturday, February 5, 2005, at 09:42 AM, Tim Bray wrote: On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document.

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Antone Roundy
On Saturday, February 5, 2005, at 03:55 PM, Sam Ruby wrote: -1 to the Pace. Just to be sure we don't forget, if we don't want to allow multiple versions of an entry in the same feed document, we need to add language to the spec to clarify that point. Like Robert, I believe that this Pace

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Antone Roundy
On Saturday, February 5, 2005, at 02:07 PM, Robert Sayre wrote: Antone Roundy wrote: On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote: Part of our charter is to define a format suitable for archiving feeds. Right, and breaking the feed format isn't the way to do it. Since you're

Re: PaceRepeatIdInDocument posted

2005-02-05 Thread Antone Roundy
On Saturday, February 5, 2005, at 06:25 PM, Antone Roundy wrote: I'd be perfectly happy with not allowing atom:id to be repeated in a feed or the hypothetical aggregation if we had an archive element which acts exactly like aggregation except that atom:id may be repeated. Oops, correction

Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Sunday, February 6, 2005, at 09:35 AM, Sam Ruby wrote: Graham wrote: On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote: If you produce feeds that contain multiple entries with the same id, there will be people who misunderstand such documents. I do believe that there needs to be some way to say this

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Antone Roundy
On Sunday, February 6, 2005, at 07:42 PM, Bob Wyman wrote: The whole feed business is simply an artifact of the polling-based model of syndication. Interesting to hear the architecture for the model that most people use today be referred to as an artifact. But yeah, to someone who doesn't used

Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 10:06 AM, Robert Sayre wrote: Walter Underwood wrote: I agree, but I would put it another way. The charter requires support for archives, but we don't have a clear model for those. Without a model, we can't spec syntax. We have feed documents. A series of feed

Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
Collecting a bunch of recent discussion into one document, how about these for a set of terms and their meanings: * Entry: An abstract term describing a unit of content and metadata associated with it. * Entry Representation: A representation of a particular state of a particular entry. *

Re: PaceArchiveDocument posted

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 10:26 AM, Bob Wyman wrote: Antone Roundy wrote: entry id revision=3foo:bar/a/id ... /entry ...where @revision is a number whose only requirement is that the number for a later revision be greater than the number

PaceNoFeedState

2005-02-07 Thread Antone Roundy
+1. There are too many little details that we haven't worked out in exactly how to reconstruct the state of a feed to try to define it now.

PaceIconAndImage

2005-02-07 Thread Antone Roundy
+1 if image is changed to logo or, even better, if image is allowed in entry. I don't care whether icon is allowed in entry, though I see no reason not to allow it.

PaceLinkEnclosure

2005-02-07 Thread Antone Roundy
+1, and +1 to calling it attachment instead of enclosure.

PaceFormatSecurity

2005-02-07 Thread Antone Roundy
+1. But let's add something to the effect of consumers MAY ignore unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not confident will not result in security problems.

PaceSecuritySection

2005-02-07 Thread Antone Roundy
-1: Not enough information. We may not need all the detail of PaceFormatSecurity, but PaceSecuritySection goes too far the other way.

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 12:00 PM, Bob Wyman wrote: In order to demonstrate polling at its most efficient, I defined and convinced a number of folk to implement RFC3229+feed. This HTTP extension eliminates the problem with sending multiple copies of messages to people and the resulting

PaceXhtmlNamespaceDiv

2005-02-07 Thread Antone Roundy
+1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in content or before content. Examples of what I'd think was acceptable: feed ... xmlns:xhtml=... / ... contentThis is

PaceCommentFeeds

2005-02-07 Thread Antone Roundy
+1: if not the whole Pace, then at least link/@rel=comments.

PaceEntriesElement

2005-02-07 Thread Antone Roundy
-1: recursion is too complex and bulky.

PaceFeedRecursive

2005-02-07 Thread Antone Roundy
-1: recursion is too complex and bulky. But we could (should?) specify lack of recursion in terms of particular types of Atom Documents or particular profiles, leaving the door open for extensions to define document types that allow recursion.

PaceRemoveVersionAttr

2005-02-07 Thread Antone Roundy
+1. I'd like to see language specifying how the namespace can be used to determine compatibility between revisions of the specification--ie. any app that can handle one version of Atom can handle any version sharing the same namespace, and any feed that's valid under any version of Atom is

PaceProfileAttribute

2005-02-07 Thread Antone Roundy
-1: One profile (or maybe set of profiles) per document is better in my opinion. If an aggregator aggregates entries with different profiles, it can either fix them up as needed to conform to a common profile, or if multiple profiles can be specified at the top level, declare the profiles for

PaceAggregationInSeparateSpec

2005-02-07 Thread Antone Roundy
+1 if: 1) it means that head-in-entry is removed. AND 2) profiles or some extension mechanism would enable people to do head-in-entry for those who want to use that method, but which I DON'T mean this: entry ext:head ext:feed-title / ext:feed-updated /

Re: PaceProfileAttribute

2005-02-07 Thread Antone Roundy
the allowing of the @profile attribute on sub-elements (e.g. entries contained in feeds) correct? This is an important distinction because I'm definitely not married to the syntax as presented but would definitely like to see us adopt the profile mechanism in general. - James M Snell Antone Roundy

Re: PaceProfile

2005-02-07 Thread Antone Roundy
On Monday, February 7, 2005, at 03:41 PM, Sam Ruby wrote: Robert Sayre wrote: James M Snell wrote: I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute

PaceAggregationDocument, PaceAggregationDocument2

2005-02-07 Thread Antone Roundy
If we adopt PaceProfile and drop head-in-entry (which could be added back in by a profile), -1 to both, otherwise +1 to PaceAggregationDocument2, or lacking that, PaceAggregationDocument.

PaceArchiveDocument

2005-02-07 Thread Antone Roundy
If we adopt PaceProfile, then -1, otherwise +1. I'd also be fine with losing the feed elements and just having archivehead /entry /*/archive

PaceXhtmlNamespaceDiv

2005-02-10 Thread Antone Roundy
I've updated the examples as follows: Removed the style attribute from the div in one--if the div is not part of the content, it doesn't make sense to me allow it to control styling of the content. Yeah, I wrote the original example, but I hadn't thought through everything clearly enough yet.

Re: draft-ietf-atompub-format-06

2005-03-16 Thread Antone Roundy
4.1.1 The atom:feed element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Its element children consist of one or more metadata elements followed by zero or more atom:entry child elements. A little

Re: Attributes on the xhtml:div wrapper

2005-03-16 Thread Antone Roundy
On Wednesday, March 16, 2005, at 03:57 PM, David Powell wrote: Should we: a) keep the current text. b) disallow attributes on the xhtml:div wrapper. c) disallow XHTML attributes on the xhtml:div wrapper, but allow xml:lang. I vote for b). Allowing xml:lang on xhtml:div is unnecessary

Re: Attributes on the xhtml:div wrapper

2005-03-17 Thread Antone Roundy
On Thursday, March 17, 2005, at 03:21 AM, Thomas Broyer wrote: Anyway, the -06 spec says XHTML is used in its basic flavor (and that's good! applause/), not allowing inline styles (but still the class attribute) nor the script element. First, just curious--did we discuss which flavor of XHTML

Re: Attributes on the xhtml:div wrapper

2005-03-17 Thread Antone Roundy
On Thursday, March 17, 2005, at 09:21 AM, Thomas Broyer wrote: Antone Roundy wrote: Second, looking at http://www.w3.org/TR/2000/REC-xhtml-basic-20001219/, I see that the style ELEMENT is not supported, but it doesn't say that the style ATTRIBUTE is not supported. That's right, you have to go

Re: Attributes on the xhtml:div wrapper

2005-03-17 Thread Antone Roundy
On Thursday, March 17, 2005, at 10:18 AM, 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 If we're going to

One link with @rel=alternative unless...

2005-03-17 Thread Antone Roundy
On Thursday, March 17, 2005, at 02:58 PM, Tim Bray wrote: [[anchor25: atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of alternate that has the same type attribute value. This requirement predates @hreflang. Keep it? --R.

Re: author requirements

2005-03-17 Thread Antone Roundy
On Thursday, March 17, 2005, at 03:12 PM, Robert Sayre wrote: C. Things that potentially require WG action: [[anchor24: What if there's a source-feed element? This is busted. We should make author required for atom:feed and optional for atom:entry. No inheritance

Re: s/url/web/

2005-03-18 Thread Antone Roundy
On Friday, March 18, 2005, at 04:24 AM, Dan Brickley wrote: URIs and IRIs are the way we identify things (on, in, to and for...) the Web. So web to me seems natural. I think the question is which of these is meant by the web: a) HTML over HTTP(S), plus images and other things that get rendered in

Re: Person identity

2005-03-18 Thread Antone Roundy
On Friday, March 18, 2005, at 08:23 AM, Thomas Broyer wrote: I propose adding an optional atom:id element to the Person construct content model, If it's not too late, I wouldn't be opposed to this, but I'm not sure I agree entirely with the specific rules. with the following rules (to be

Re: application/rss+xml

2005-03-30 Thread Antone Roundy
On Tuesday, March 29, 2005, at 11:00 PM, Mark Nottingham wrote: Of course, given that RSS has separate change controllers, it might be argued that it would be better to have different ones, but I'm not yet convinced; generally, you've got one app that can handle all of the formats; there's no

Re: Why is alternate link a MUST?

2005-04-04 Thread Antone Roundy
On Sunday, April 3, 2005, at 11:05 AM, Brett Lindsley wrote: Consider a feed returned as a result of a search operation (e.g. a time range). To create an alternate representation of this resource, the link must also specify the same conditions that resulted in the search results. That is, the

Re: PaceFeedIdOrAlternate

2005-04-04 Thread Antone Roundy
I think requiring either atom:id or atom:[EMAIL PROTECTED]self] would make more sense. It's entirely conceivable that multiple feeds might exist that claim to be alternates of the same resource--for example, a full content feed vs. a summary feed; a scraped feed vs. an official feed (...in

PaceFeedIdOrSelf

2005-04-04 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf Note that this proposal makes alternate a SHOULD, not a MAY. This is to say that if you've got an alternate, you SHOULD link to it. I don't particularly care whether that's SHOULD or MAY. === Abstract Require either a self link

Re: Obs on format-07

2005-04-06 Thread Antone Roundy
On Wednesday, April 6, 2005, at 07:50 PM, Bill de hÓra wrote: Note: the following example is not well formed unless the XHTML namespace has been bound previously to the xh prefix in the document: +1 to the concept, but perhaps it could be worded a little differently, eg. 'Note: the following

Re: PaceCoConstraintsAreBad

2005-04-06 Thread Antone Roundy
On Wednesday, April 6, 2005, at 08:40 PM, Sam Ruby wrote: My order of preference: PaceFeedIdOrAlternate PaceFeedIdOrSelf Current Text PaceCoConstraintsAreBad To summarize what elements would be required under each, all four require atom:title and atom:updated. Additionally: Current

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

2005-04-14 Thread Antone Roundy
On Thursday, April 14, 2005, at 06:04 AM, Bill de hÓra wrote: I don't think is comes under the category of namespaces for versioning problem. We made this problem ourselves, due to the consensus view that says default namespaces are so valuable we have the bake an inverted dependency into

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

2005-04-14 Thread Antone Roundy
...back in town, and ready to express opinions... Thomas Broyer wrote: Bob Wyman wrote: Robert Sayre wrote: You can point to an alternate feed like this link rel=alternate type=some/feed href=... / Of course, you can't have two alternates with the same media type... Yes, you can point to an

Re: Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments)

2005-04-15 Thread Antone Roundy
On Friday, April 15, 2005, at 02:14 AM, Asbjørn Ulsberg wrote: But even though I see it is a major hack, won't putting Content Constructs inside the target namespace of the embedded content be a solution to tell what type of content we are embedding without having to use a 'type' element? I

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

2005-04-15 Thread Antone Roundy
On Friday, April 15, 2005, at 02:30 PM, A. Pagaltzis wrote: * 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

Trade mandatory xhtml:div for atom:content/@container?

2005-04-15 Thread Antone Roundy
In case the idea was buried too deeply in my prior email[1], here it is in it's own message: Could we drop the xhtml:div requirement in [EMAIL PROTECTED]xhtml], and instead clarify the status of the div that is commonly being put there (is it part of the content or not?) by adding an attribute

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

2005-04-15 Thread Antone Roundy
On Friday, April 15, 2005, at 03:51 PM, A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-04-15 23:05]: 2) It makes it more difficult to determine the type of data. We know it's XML, but to find out whether it's a flavor of XML that we know how to deal with, we have to discover

Re: Trade mandatory xhtml:div for atom:content/@container?

2005-04-16 Thread Antone Roundy
On Friday, April 15, 2005, at 04:15 PM, Thomas Broyer wrote: Antone Roundy wrote: Could we drop the xhtml:div requirement in [EMAIL PROTECTED]xhtml], +1 and instead clarify the status of the div that is commonly being put there (is it part of the content or not?) +1 by adding an attribute

PaceXmlContentWrapper

2005-04-19 Thread Antone Roundy
It may be too late, but either way, I'd like to get this into concrete form. Does anyone think this is worse than requiring the xhtml:div? Better? http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper == Abstract == Replace the requirement for an xhtml:div wrapper for

Re: NoIndex, again

2005-04-19 Thread Antone Roundy
I believe we decided not to address licensing in the Atom core because the probability of not getting it quite right is too high, especially given the differences between laws in various jurisdictions around the world. Having something in the core might require consuming applications to

  1   2   3   >