James M Snell wrote:
Bob Wyman wrote:
Andreas Sewe wrote:
So, it looks like that quoting the type parameter's values is no
longer allowed;
Are the quotes part of the parameter value? Or, are quotes merely
delimiters of the value? If RFC045 is read to indicate that the
quotes
While RFC 2045 specifically allows quoted parameter values and defines
application/atom+xml;type=feed to be equivalent to
application/atom+xml;type=feed, RFC 4288 states that '[t]here is no
defined syntax for parameter values. Therefore registrations MUST
specify parameter value syntax.'
Sylvain Hellegouarch wrote:
Hugh Winkler wrote:
The draft makes no mention of file extensions.
Server software responsible for inserting correct Content-type header
can *possibly* set the correct value when serving a file, if the
type=entry and type=feed documents have distinct file
,
Andreas Sewe
of Entry Documents
application/atom+xml or not; some Entry Documents have already escaped
into the wild.
Regards,
Andreas Sewe
for a
different purpose. For (optional) type/profile parameters, however,
there is precedent.
As for Tim's concerns, I'd also prefer having it done outside the APP.
+1. A separate Atom Media Types RFC would be good.
Andreas Sewe
.
Regards,
Andreas Sewe
Mark Nottingham wrote:
Andreas Sewe wrote:
But it would be desirable, IMHO, to be able to link to archived, older
versions of a complete feed from within the current complete feed
document.
Say, a feed document contains this month's Top Ten. Wouldn't it be
nice if the feed document could
Thomas Broyer wrote:
2006/10/9, Andreas Sewe:
But while the draft states that [t]hese [feed] types are complementary
(section 1), but is unfortunately silent on how precisely the three
different types can be used together.
Here are a few questions I still have:
- Is it possible
Mark Nottingham wrote:
I've only had positive comments about -07 so far, so I've recommended it
for publication as a Proposed Standard to the IESG.
Congratulations!
But while the draft states that [t]hese [feed] types are complementary
(section 1), but is unfortunately silent on how
relations, not bare names. (They would even benefit from it,
since some experimental http://microformats.org/relation/foo relation
would not require IANA registration.)
Regards,
Andreas Sewe
and media type. Everything else is just confusing
for no good reason.
Regards,
Andreas Sewe
FWIW, I have set the Reply-To to atom-protocol, since it seems to be the
more appropriate list to discuss these things -- not that it really
matters, given the overlap between atom-syntax's and atom-protocol's
of Atom's
built-in metadata (I still remember the PaceDate* debate), this seems
like a good idea to me. So, are there already efforts in this direction?
Regards,
Andreas Sewe
James Holderness wrote:
For the second I'd recommend this:
link rel=ALTERNATE
href=http://www.snellspace.com/public/alternate2; /
link rel=alternate
href=http://www.snellspace.com/public/alternate; /
link rel=ALTERNATE
datatyping being included as well --
iff we can come up with a solution which can describe all the common
uses cases out there!
Andreas Sewe
Thomas Broyer wrote:
Andreas Sewe wrote:
If the value of the steps attribute is continuous the set of rank
values defined by the r:values element is
{ x | minimum = x = maximum }.
And @origin is ignored?
Well, it is not really ignored but irrelevant, since a value for @steps
James M Snell wrote:
Andreas Sewe wrote:
Now the current draft defines two elements, r:value and r:range, for
this purpose. Those two elements can be, however, be collapsed into a
single one, and, with cleverly chosen defaults, defining sets using this
new r:values element is IMHO as simple
Robert Sayre wrote:
Andreas Sewe [EMAIL PROTECTED] wrote:
But does this sound like an improvement to you, too?
Sort of. I did a deep dive on this, and I think it's really huge.
It's had little community input, it's not at all clear that the
approach is correct, and it's not clear
origin and steps do, in
plain English, is unfortunately surprisingly difficult. :-(
Looking forwards to your feedback,
Andreas Sewe
like an improvement to you, too?
Best wishes,
Andreas Sewe
Zorkmids.
Andreas Sewe
) to the values just registered.
Too bad the values used are inconsistent with XHTML rel values, though,
but then again I probably suffer from syntactic hypersensitivity. ;-)
Anyways, back to lurking...
Andreas Sewe
attribute or to
HTTP's Content-Type as well?
Regards,
Andreas Sewe
counterparts. And APP should follow the
rule of least astonishment here.
Regards,
Andreas Sewe
.
Regards,
Andreas Sewe
of the above entries is preferable?
Regards,
Andreas Sewe
realize -- and I should better serve the mails as text/plain
or convert them to HTML first (which is the way the atom-syntax
archive works).
Nevertheless, any advice on this issue would be greatly appreciated.
Regards,
Andreas Sewe
Thomas Broyer wrote:
Antone Roundy wrote:
This raises a few questions:
1) How does one indicate the existence of variants?
[EMAIL PROTECTED]alternate or using a custom (read: extension)
relations or using extension elements. See also my comments
below on 3).
I'll just stop lurking for a minute
28 matches
Mail list logo
