James M Snell wrote:
If you want to use the text/vnd.IPTC.NewsML media type to
identify the type of XML, then you'd have to escape the markup and treat
it like text.
s/escape/Base64/
s/like text/as binary/
- Sam Ruby
you, originally); I was wrong.
I don't see the ambiguity.
- James
James Holderness wrote:
Sam Ruby wrote:
James M Snell wrote:
If you want to use the text/vnd.IPTC.NewsML media type to
identify the type of XML, then you'd have to escape the markup and treat
it like text.
s/escape/Base64/
s
Joe Gregorio wrote:
On 12/14/06, Sam Ruby [EMAIL PROTECTED] wrote:
I believe I first saw this in a response made by Roy Fielding to an
assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I
can't immediately find the reference.
http://www.imc.org/atom-protocol/mail-archive
-parameter option.
If a few people were to put up their hands and say yeah what Bob said
your co-chairs would probably do a hasty consensus grab./co-chair-mode
+1 to what Bob said
- Sam Ruby
request the server choses to process. Such requests could
partially or completely change the representation of the resource.
- Sam Ruby
PaceOrderCollectionsByAppModified2
PaceRemoveConnegSuggestionOnServiceDoc
PaceRemoveOutOfLineCategoriesFromCategoryDocument
PaceRevertTitle
PaceSecurityConsiderationsRevised
PaceServiceLinkType
UseElementsForAppCollectionTitles2
UseElementsForAppCollectionTitles3
- Sam Ruby
tends to catch things like unmatched angle brackets and quotes.
Also, there are a number of tools that attempt to produce well-formed
XHTML, but don't do so consistently enough to drop the content into an
Atom feed in such a manner.
- Sam Ruby
Robert Sayre wrote:
I'll file a bug
on UFP and I bet you it'll get fixed without a question
http://sourceforge.net/tracker/index.php?func=detailaid=1474256group_id=112328atid=661937
- Sam Ruby
http://planet.intertwingly.net/AtomConformanceTests/
It would be helpful if every entry had a distinct atom:id. And if the
tests were valid:
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fplasmasturm.org%2Fattic%2Fatom-tests%2Fxmlbase.atom
- Sam Ruby
Antone Roundy wrote:
Sam,
Funny that this should come up today given the recent discussion on the
mailing list--NetNewsWire isn't getting the links in your Atom feed
right.
There is an off chance that I have been following the list. ;-)
- Sam Ruby
Antone Roundy wrote:
On Mar 31, 2006, at 4:12 PM, Sam Ruby wrote:
Antone Roundy wrote:
Sam,
Funny that this should come up today given the recent discussion on
the
mailing list--NetNewsWire isn't getting the links in your Atom feed
right.
There is an off chance that I have been
that strips leading {{{
and trailing }}} and then delivers the results raw, with the appropriate
mime type.
How does ?action=atomtest sound?
- Sam Ruby
to pubDate? If any atom date is converted
to pubDate, why isn't it atom:published?
- Sam Ruby
in a matter of hours.
- Sam Ruby
atom:summary would do. Or you could create your own.
- Sam Ruby
. One
of the reasons why it has avoided being such is that I try to rely
directly on the wording from the spec whenever possible.
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3
- Sam Ruby
/AcceptHeaders
Based on the results, I will gladly start sending my feed at
application/atom+xml to those browsers that *don't* indicate a
preference for application/xml.
As well as make a change to the Feed Validator to send such a header itself.
- Sam Ruby
for other readers.
(Remember also the discussion here about the support of updated.)
Some results can be found here:
http://www.intertwingly.net/wiki/pie/ConformanceTests
Please feel free to add more.
- Sam Ruby
Robert Sayre wrote:
On 11/30/05, Sam Ruby [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
I noticed you moved PaceFeedsNotCollections and PaceSimpleIntroduction
into the Closed section.
http://www.imc.org/atom-protocol/mail-archive/msg03545.html
And, unless I misinterpreted, both Paul
Robert Sayre wrote:
On 11/30/05, Sam Ruby [EMAIL PROTECTED] wrote:
Sceduling the remaining Introspection/Collection paces as well as the
ones that are under active discussion anyway:
Additionally, I'm recommending the following for closure:
Hi Sam!
I noticed you moved
by PaceAppDocuments2:
PaceAppDocuments
PaceCollectionClasses
As always, discussion of these paces should occur on the atom protocol
list, with a subject line identifying which pace you are expressing an
opinion on.
- Sam Ruby
Sjoerd Visscher wrote:
Sam Ruby wrote:
URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform
xml:base = http://w3future.com/weblog/rss.xml?notransform
Ah, ok, I missed that. (Just to be sure, you added www yourself, or is
there a link to the feed somewhere with www
.
Note that if your application were to discard all the data it receives
before it encouters the first entry, the stream from there on out would
be identical.
- Sam Ruby
made the same suggestion
that Bob did. Brad indicated that if there were clients with different
requirements, he was amenable to accommodating each - endpoints are cheap.
- Sam Ruby
Sjoerd Visscher wrote:
Sam Ruby wrote:
Apparently, consuming tools are welcome to aggressively substitute
references to the enclosing parent document of any element for any
references that, when resolved according to xml:base, differ from that
xml:base only in ways that deal
that you are unlikely to directly reference later
in the document. Referencing a parent directory of any given document
is OK, what's important is that it isn't the document itself.
And to include an example that matches what Sjoerd's feed (and now Tim's
feed) now do.
Fair enough?
- Sam Ruby
Sjoerd Visscher wrote:
Sam Ruby wrote:
Apparently, consuming tools are welcome to aggressively substitute
references to the enclosing parent document of any element for any
references that, when resolved according to xml:base, differ from that
xml:base only in ways that deal
the specification, particularly if there is no compelling use case for
use of the feature.
Can we agree that empty //atom:link/@href values, or //atom:link/@href
values that consist entirely of a fragment are problematic?
- Sam Ruby
document. In
either case speak now if you feel otherwise.
- Sam Ruby
, this paragraph talks about the *Atom
Document* moving, rather than the content that it represents (i.e. a
blog).
Perhaps we could add or its associated resource after Atom Document?
+1
- Sam Ruby
Tim Bray wrote:
On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:
Tim Bray wrote:
I'm getting increasingly grumpy and just fail is looking better and
better. The current normative text, The element's content MUST be an
IRI, is clear and simple and supported by other well-understood
dispute your read on the consensus of the working group, but I
would like to request that *SOME* language be present in the spec that
makes this clear.
- Sam Ruby
,
(atomUri)
}
# Unconstrained; it's not entirely clear how IRI fit into
# xsd:anyURI so let's not try to constrain it here
atomUri = text
- Sam Ruby
decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
- Sam Ruby
2:
Datatypes Second Edition, W3C Recommendation 28 October 2004.
- Sam Ruby
).
But I wouldn't recommend it. To me, doing so would be akin to mailing
fragile equipment and paying for insurance, in the hopes of getting the
opportunity to express indignation at the post office.
- Sam Ruby
[1] http://www.imc.org/atom-syntax/mail-archive/msg16243.html
elements in the Atom
namespace which are not defined in this revision of the specification.
- Sam Ruby
http://www.atomenabled.org/developers/syndication/
Feedback welcome.
- Sam Ruby
Sjoerd Visscher wrote:
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers
Sjoerd Visscher wrote:
Tim Bray wrote:
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
And that's why you can't use it as a reference to your site.
To quote from RFC 3986:
When a URI reference refers
to accessible resources?
- Sam Ruby
$0.02.
- Sam Ruby
.
When I feel that the feedvalidator is anywhere near ready to be
considered seriously for Atom 1.0 feeds, I'll post something on my weblog.
- Sam Ruby
this as a problem (first as a warning, and later I
will change this to an error).
- Sam Ruby
Robert Sayre wrote:
So, -1 to mentioning Atom 0.3 at all.
I agree with Robert.
Note how Atom 0.2 isn't a problem at all... we can (and will) do the
same thing with Atom 0.3.
- Sam Ruby
, and there might even be an
occasion or two where I have been overzealous.
My experience has been that this is only a starter set at best, as the
set of possible errors that people will attempt is well beyond anything
that one can possibly anticipate.
Corrections welcome.
- Sam Ruby
Joe Gregorio wrote:
On 6/17/05, Sam Ruby [EMAIL PROTECTED] wrote:
P.S. Why is this on atom-sytax? Is there a concrete proposal we are
talking about here? Is there likely to be?
Were you expecting [atom-syntax] to vanish in a puff of smoke
once we have a couple RFCs under our belt? Given
the two.
And perhaps they could be combined. I could see a future where there
was a feedmesh backbone with nodes exchanging data via XMPP, serving
content out to the rest of the universe via HTTP.
- Sam Ruby
P.S. Why is this on atom-sytax? Is there a concrete proposal we are
talking
...
/entry
/content
/entry
/feed
Entirely legal, but who wants to bet the feed validator throws a fit ;-)
I'll take that bet.
- Sam Ruby
what topic your presentation is supposed to cover, but
hopefully there is room to mention the protocol.
- Sam Ruby
and content:
http://www.imc.org/atom-syntax/mail-archive/msg15208.html
http://www.imc.org/atom-syntax/mail-archive/msg15266.html
- Sam Ruby
Tim Bray wrote:
On May 18, 2005, at 6:19 PM, Sam Ruby wrote:
Isn't that redundant? From PaceOptionalSummary:
Yup. Think we got that covered. -Tim
Off list, Robert pointed out to me that that the spec text I cited
didn't cover empty summaries. He's right.
- Sam Ruby
Tim Bray wrote:
On May 18, 2005, at 9:11 AM, Sam Ruby wrote:
There seemed to be consensus that feeds needed something to identify
them. What there wasn't consensus on is which element should be
that identifier. The solution selected was to make none of the
identifiers required
Sam Ruby wrote:
Tim Bray wrote:
On behalf of Paul and myself.
Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
The volume of correspondence was unfortunately high for an IETF Last
Call that came after a Working Group Last call. It is quite possible,
as always
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 or
atom:content element.
Sam Ruby wrote:
Much of the discussion of this pace centered around the proposed changes
to section 4.1.2
the entry
contains no atom:content element, and a non-empty atom:content element
when that element is present.
That works. Thanks!
- Sam Ruby
(also referred to as change control) is
needed. There does seem to be a lot of voices in support of the
following statement:
Only those elements defined in IETF RFCs may use the Atom namespace
- Sam Ruby
as a consequence of such an absence.
Much of the discussion of this pace centered around the proposed changes
to section 4.1.2. However, there is more to this pace.
- Sam Ruby
is overly burdensome.
- Sam Ruby
in those
instances where entries with duplicate ids are present in a feed?
4) No semantics can be inferred by two different entries with two
different ids sharing the same version.
- Sam Ruby
that nobody else is allowed to use the Atom namespace, coupled
with a statement that everybody must ignore elements that they don't
understand paves the way for future IETF spec authors to safely add
optional elements in a backwards compatible manner.
- Sam Ruby
the processor may place the
emphasis of its processing on the summary. The feed as a whole is still
valid, however, and it's expected that processors will handle entries
that DO have summaries in the same feed as entries that do NOT.
Very nice.
- Sam Ruby
all calm down for a few
days, and discussion things other than text elements. And when we do
revisit this discussion early next week, lets not start with
atom:summary, OK?
- Sam Ruby
Robert Sayre wrote:
On 5/9/05, Sam Ruby [EMAIL PROTECTED] wrote:
I also feel the need to express deep dismay at the way that author of
PaceOptionalSummary has been pursuing a scorched earth approach whereby
everybody who expresses an opinion to the contrary is viciously attacked
for doing so. I
Walter Underwood wrote:
I'd also be happy with just Atom and saying RFC Atom when
pressed for a version.
+1
- Sam Ruby
of all other Paces on the subject to consider... what happens
if the chairs determine that consensus can't be found on either of these
paces? Look at the current wording of draft-08. Is that what you
really want?
We can do better.
- Sam Ruby
Graham wrote:
On 6 May 2005, at 3:50 am, Sam Ruby wrote:
FYI: we have an instance proof of this requiring an existing tool to
do additional work:
http://www.imc.org/atom-syntax/mail-archive/msg13983.html
Tools will have to be updated to work with Atom? Scandalous.
+1 to the Pace
This Pace
of the proposal. It is part of the rationale.
- Sam Ruby
?
- Sam Ruby
this to responsibility to a more appropriate home.
- Sam Ruby
a
separate id element (or in RSS 2.0's case, utilizing the guid element)
would be more to the point.
- Sam Ruby
change over time. Perhaps atom:source elements could also define an
@updated attribute. As atom:updated is a required element for
atom:entry, it would not be an unreasonable burden to require @updated
attributes on atom:source elements.
- Sam Ruby
paces touches on the format, I've
scheduled all three. All we need to resolve now is the extent to which
this is going to affect the format document.
I believe that PaceBriefExample is truly editorial, meaning that the
editors can act on this at their discretion.
- Sam Ruby
[1] http
Walter Underwood wrote:
--On May 5, 2005 7:17:00 AM -0400 Sam Ruby [EMAIL PROTECTED] wrote:
Demonstrate that you have revisited the previous discussion, and that you either
have something new to add, or can point out some evidence that the previous
consensus call was made in error.
PaceCaching
fate?
- Sam Ruby
proof of this requiring an existing tool to do
additional work:
http://www.imc.org/atom-syntax/mail-archive/msg13983.html
- Sam Ruby
+1
From prior discussion, people have indicated that they want *something*
that they can use to track feeds identity, and the consensus seemed to
be that id and/or self was more appropriate than link.
- Sam Ruby
that
particular proposal was brought before the working group?
- Sam Ruby
Robert Sayre wrote:
On 4/29/05, Sam Ruby [EMAIL PROTECTED] wrote:
== Abstract ==
Encourage interoperability and accessibility by suggesting that key
textual constructs be both present and non-empty.
I'd prefer that a bit more of the rationale made it into the text.
Explain why we are saying SHOULD
be
consensus that unique by source is sufficient.
- Sam Ruby
the format to your app.
Robert: why did you ask for an example?
- Sam Ruby
. Quoting from RSS 0.92[1]:
* All sub-elements of item are optional
* any 0.92 source is also a valid 2.0 source
Is this really where we want to go?
- Sam Ruby
[1] http://backend.userland.com/rss092
compromise.
- Sam Ruby
discussions. Schedule be damned.
- Sam Ruby
of this. This is why I think it makes more sense as a
SHOULD requirement.
Well stated. I'd also add that apparently summary SHOULD be non empty
in all of the cases where it is currently required as well as one new
case: the case where the content is empty.
- Sam Ruby
Robert Sayre wrote:
On 4/26/05, Sam Ruby [EMAIL PROTECTED] wrote:
Graham wrote:
The pace as written newly allows the omission of a summary and content
on the whim of the publisher.
That's right.
I'm within my rights as a
consumer to reject title-only feeds as not worth bothering with (before
of whether tools like RNG grammars and feedvalidators
can assist people who produce feeds in making their intents clear.
- Sam Ruby
of such
elements would have prevented.
I have seen no arguments as to why placing such empty elements would
impose an unreasonable burden on implementers.
- Sam Ruby
Robert Sayre wrote:
Sam Ruby wrote:
If, instead, it opens the door for multiple changes without explicit
rationale; at the last minute; overturning carefully formed consensus;
then it was not.
Uh, so your changes are ok, but mine aren't? We continue the lovely
pattern of DOSing proposals
Robert Sayre wrote:
Sam Ruby wrote:
Content remains optional.
The pace did not drop the requirement for a link element in the absence
of content.
OK, I missed that. What else did I miss at this late date?
As it stands, this Pace declares co-constraints bad, selectively removes
a few co
Robert Sayre wrote:
Sam Ruby wrote:
At this point, small surgical changes to address specific concerns may
(or may not) be acceptable. Wholesale changes with little rationale
are less likely to be so.
Well, who really cares anyway. I'll get the draft ready. Nobody propose
any 'wholesale
an element mandatory.
co-constraints are bad.
Entries without either a summary or content or even a link to where you
can find the data are worse.
-1
- Sam Ruby
P.S. If it pleases your sense of aesthetics, merge these three elements
into one mandatory element, with an attribute to specify whether
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
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
to a SHOULD or
MUST would require a separate Pace.
- Sam Ruby
:
http://intertwingly.net/wiki/pie/LinkTagMeaning
http://www.xml.com/lpt/a/2004/06/16/dive.html
- Sam Ruby
) collection or
sub-collection
* not provide for index-based ranges, or other kinds of searches.
If I can have this done by the end of the day, could we discuss it in this
round?
Yes.
- Sam Ruby
, should be make the TYPE attribute
optional)
- Sam Ruby
ids as it indicated an error in
their software.
- Sam Ruby
that THIS IS NOT A MEDIA-TYPE, but I'm not religious about it. -Tim
I PERSONALLY DON'T THINK THAT SHOUTING IS NECESSARY.
- Sam Ruby
P.S. ;-)
1 - 100 of 159 matches
Mail list logo
