Are the next and previous links that we thought may be attachable
to the feed
really too controversial to get into the final atom spec? They would be
really useful
to archive feeds.
Henry Story
Here are some more -07 review comments from one member of the XML
Directorate. We already know about #1. It's OK to ask questions about the
reviewer's questions, just please cc him directly if you wish to start a
dialog.
-Scott-
-Original Message-
From: Andrew Newton [mailto:[EMAIL
At 11:28 AM +0200 4/6/05, Henry Story wrote:
Are the next and previous links that we thought may be
attachable to the feed
really too controversial to get into the final atom spec?
It doesn't matter whether or not they are too controversial; the
spec is frozen for significant technical changes.
Paul Hoffman wrote:
At 11:28 AM +0200 4/6/05, Henry Story wrote:
Are the next and previous links that we thought may be attachable
to the feed
really too controversial to get into the final atom spec?
It doesn't matter whether or not they are too controversial; the spec
is frozen for
http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad
Abstract
Require atom:id, atom:title, atom:updated, atom:author. That's it.
Status
Open
Rationale
The spec delivers value when it can make an element mandatory.
On Apr 5, 2005, at 9:26 AM, Tim Bray wrote:
Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt
instead
of RFC 2234 and confirm that everything that was valid before is still
valid. The IESG approved this document as a Draft Standard last week.
Rob/Mark?
Hmm. As far as I can tell,
I can do that later tonight.
On Apr 6, 2005, at 5:37 PM, Tim Bray wrote:
On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote:
Anything to add?
No, I think Rob's got it. Sooner is better.
Who's going to take care of submitting the MIME type registration? A
volunteer would be welcome. -Tim
Julian
Tim Bray wrote:
On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote:
Anything to add?
No, I think Rob's got it. Sooner is better.
Who's going to take care of submitting the MIME type registration? A
volunteer would be welcome.
I'm unable to discern any consensus around the cardinality constraints
Hi editors,
Comments and observations on the 07 draft.
** RNC Schema
- is valid rnc
- the schema and the fragments appear to be consistent.
- both examples validate according to the supplied schema
- the xhtml fragments in 4.1.3.4 validate when embedded as specified.
- in 6.4; simple and
Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad
Abstract
Require atom:id, atom:title, atom:updated, atom:author. That's it.
Status
Open
Rationale
The spec delivers value when it can make an
Sam Ruby wrote:
co-constraints are bad.
Entries without either a summary or content or even a link to where you
can find the data are worse.
Does my Pace allow such a creature?
Robert Sayre
On Apr 6, 2005, at 6:50 PM, Bill de hÓra wrote:
Hi editors,
Comments and observations on the 07 draft.
Most seem OK to me, but...
replace
[[[
The following example assumes that the XHTML namespace has been bound
to the xh prefix earlier in the document:
]]]
with
Note: the following example is
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
Robert Sayre wrote:
Sam Ruby wrote:
co-constraints are bad.
Entries without either a summary or content or even a link to where
you can find the data are worse.
Does my Pace allow such a creature?
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a
Sam Ruby wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint, and we fail to meet the requirements of our charter for any
An additional observation: neither of the examples in section 1.1
include the summary element. Suggestion: change the content in the
first (minimal) example to summary.
- Sam Ruby
Sam Ruby wrote:
An additional observation: neither of the examples in section 1.1
include the summary element. Suggestion: change the content in the
first (minimal) example to summary.
summary/?
Robert Sayre
On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are incorrect. There was an
On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote:
Sam Ruby wrote:
An additional observation: neither of the examples in section 1.1
include the summary element. Suggestion: change the content in the
first (minimal) example to summary.
summary/?
No. --Tim
Done;
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/
000676.html
Just curious; when/how does the ietf-types list switch over to
@iana.org (as per draft-freed-media-type-reg)?
On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote:
The MIME media type registration template
Tim Bray wrote:
On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are
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
22 matches
Mail list logo
