t (as were 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.
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
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/m
ient issued
and the next request the server choses to process. Such requests could
partially or completely change the representation of the resource.
- Sam Ruby
-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.
+1 to "what Bob said"
- Sam Ruby
ntsToEntry
PaceOrderCollectionsByAppModified2
PaceRemoveConnegSuggestionOnServiceDoc
PaceRemoveOutOfLineCategoriesFromCategoryDocument
PaceRevertTitle
PaceSecurityConsiderationsRevised
PaceServiceLinkType
UseElementsForAppCollectionTitles2
UseElementsForAppCollectionTitles3
- Sam Ruby
Given the rather loose nature of HTML,
this only 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=detail&aid=1474256&group_id=112328&atid=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
pecific action just for this wiki that strips leading {{{
and trailing }}} and then delivers the results raw, with the appropriate
mime type.
How does ?action=atomtest sound?
- 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'
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
hy is atom:updated converted to pubDate? If any atom date is converted
to pubDate, why isn't it atom:published?
- Sam Ruby
be deployed online in a matter of hours.
- Sam Ruby
t element, in
a namespace. Perhaps atom:summary would do. Or you could create your own.
- Sam Ruby
narios. How will this be expressed in
RFC 822 format?
How about content that is in a binary format?
I can go on...
> Any case of data-loss is a bug that we'll address
If that is a blanket statement, then I expect that you will be seeing a
lot of bug reports.
- Sam Ruby
context of syndication, the Feed
Validator has the potential for being in the center of controversy. 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
http://www.intertwingly.net/wiki/pie/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
other readers.
(Remember also the discussion here about the support of .)
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 Pa
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 notice
ource
PaceServiceDescription
- Sam Ruby
PaceXHTMLIntrospection2
- Sam Ruby
[1] http://www.imc.org/atom-protocol/mail-archive/msg02970.html
ed 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
independently 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
and SAX, the "absolute simplest solution" is
what Bob is describing: a single document that never completes.
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
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 you
Sjoerd Visscher wrote:
>
> Sam Ruby wrote:
>
>> Sjoerd Visscher wrote:
>>
>>> Sam Ruby wrote:
>>>
>>>
>>>> Sjoerd, I'd be interested in your comments on this:
>>>>
>>>> http://tinyurl.com/9o6y2
>&g
Sjoerd Visscher wrote:
> Sam Ruby wrote:
>
>> Sjoerd, I'd be interested in your comments on this:
>>
>> http://tinyurl.com/9o6y2
>
> The explanation in the documentation[1] is perfect. And it says "As the
> current xml:base in effect does not match
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
>>
ontain an id element, and that entries contain some textual
content (either in a summary or in content).
- 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
>>
nt itself.
And to include an example that matches what Sjoerd's feed (and now Tim's
feed) now do.
Fair enough?
- Sam Ruby
the format document. In
either case speak now if you feel otherwise.
- Sam Ruby
blematic.
My reading of this statement is that your feed also contains a
problematic link. Issuing warnings on what is unambiguously a fully
qualified URI and on your usage are things I would rather avoid.
- Sam Ruby
ght have differing opinions of how to read
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
actually says. As you point
out, it is "really odd" that nothing was added to the new RFC 3986 to
support your position.
The authors of DOM3 looked at both the xml:base and InfoSet
specifications. I've taken a look at how two respected XML parsers have
implemented DOM3:
http://www.intertwingly.net/blog/2005/08/12/xml-base-support
- Sam Ruby
gt; atom:id
> element MUST NOT change.". For me, 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 M
Bill de hÓra wrote:
> 0. The validator isn't the spec.
+1 to the sentiment that the validator isn't the spec.
- Sam Ruby
;content" is open to intelligent dispute.
Apparently the authors of RFC3470/BCP70 believe so too.
I won't 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
luding
the isegment-nz-nc production), MIME media types, language tags,
lengths, addr-spec, and date-time productions would lead to improved
interoperability.
I'm fine with either.
- Sam Ruby
of Mac, DOS, and Unix styles).
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
://www.atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.3.3>),
> how exactly does this allow whitespace around the xsd:datetime value???
Take a look at sections 3.2.7.6 and 4.3.6 of XML Schema Part 2:
Datatypes Second Edition, W3C Recommendation 28 October 2004.
- Sam Ruby
right thing.
Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
- Sam Ruby
es ·derived· by
·restriction· from it) the value of whiteSpace is collapse and
cannot be changed by a schema author; for string the value of
whiteSpace is preserve; for any type ·derived· by ·restriction· from
string the value of whiteSpace can be any of the three legal values.
That being said, the RNC grammar for atom contains:
atomId = element atom:id {
atomCommonAttributes,
(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
http://www.atomenabled.org/developers/syndication/
Feedback welcome.
- Sam Ruby
ce is reserved for future forwards-compatable
revisions of Atom.
Which would enable the text in appendix B to simply state:
The RelaxNG grammar explicitly excludes elements in the Atom
namespace which are not defined in this revision of the specification.
- Sam Ruby
s truly a nit:
If neither the type attribute nor the source attribute is provided,
Atom Processors MUST behave as though it were present with a value
of "text".
What is "it"? The type attribute? The source attribute?
Suggestion:
s/ it / the type attribute /
- 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 39
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 39
kis, and do what we thought was best.
But Atom 1.0 is much better. Much.
My $0.02.
- Sam Ruby
complete), how much
value do you think that there would be value in an option to attempt to
verify all potentially dereferencable URIs resolve to accessible resources?
- Sam Ruby
days.
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
, 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
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
o update the
feedvalidator to note this as a problem (first as a warning, and later I
will change this to an error).
- Sam Ruby
ind other deviations from the recommended practices, I'll note
them here.
- 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 ou
this ban was.
I don't really see why we are banning these MIME types from either
local or remote content.
http://www.intertwingly.net/wiki/pie/PaceReformedContent3
- Sam Ruby
tions, with a wide overlap between 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?
kely to support this is likely to be
vanishingly small.
- Sam Ruby
-Tim
On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:
http://www.example.org/lists/list/archive/12345"/>
Unfortunately, that's bad Atom. Section 4.1.3.1 of the format spec
says;
On the atom:content element
wants to bet the feed validator throws a fit ;-)
I'll take that bet.
- Sam Ruby
Is:
http://intertwingly.net/slides/2003/xmlconf/34.html
Add clear distinction between summary and content:
http://www.imc.org/atom-syntax/mail-archive/msg15208.html
http://www.imc.org/atom-syntax/mail-archive/msg15266.html
- Sam Ruby
m not certain what topic your presentation is supposed to cover, but
hopefully there is room to mention the protocol.
- 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 req
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
ains content that is encoded in Base64; i.e.
the "type" attribute of atom:content is a MIME media type
[MIMEREG] and does not begin with "text/" nor end with "+xml".
- Sam Ruby
entry
contains no atom:content element, and a non-empty atom:content element
when that element is present.
That works. Thanks!
- Sam Ruby
when some general-purpose applications encounter such
entries, those entries might be ignored.
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 or
atom:content
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, that the
error and software MUST NOT fail to function
correctly 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
I'm not sure what the next step is, but some determination of
consensus on extensibility (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
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
os.
...
My trip...
My trip to the beach
http://example.org";>
Does the same principle apply to attributes?
If a validator can't catch typos, what's left?
- Sam Ruby
mandatory except 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
so in their own namespace is overly burdensome.
- Sam Ruby
ecause 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
imply saying that that option is open to us.
With all this in mind, my suggestion is that we 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
f.org/rfc/rfc2119.txt | grep -i fail | wc
http://www.imc.org/atom-syntax/mail-archive/msg14533.html
- Sam Ruby
Walter Underwood wrote:
I'd also be happy with just "Atom" and saying "RFC Atom" when
pressed for a version.
+1
- 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
exclusion 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
e ID in a feed, it still is true that entries
may 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
Robert Sayre wrote:
On 5/6/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
At the moment, alternate link is the element of record.
Do any applications use it as such? In my experience, applications use
the URI they retrieved the feed from as the feed identifier. For
example, I believe every
ead of adding a dynamic content flag, having a
separate id element (or in RSS 2.0's case, utilizing the guid element)
would be more to the point.
- Sam Ruby
but I learn quick)
+1 to any Pace that moves this to responsibility to a more appropriate home.
- Sam Ruby
Bill de hÓra wrote:
Sam Ruby wrote:
Bill de hÓra wrote:
PaceFeedIdOrAlternate, withdrawn, no comment
PaceFeedIdOrSelf 0
PaceOptionalFeedLink +1
I agree with the rationale; no point making people things they can't
do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is
assumption?
- Sam Ruby
uot;
Um, that text is not part of the proposal. It is part of the rationale.
- 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 is
last looked. The proposed text for 4.1.2
didn't used to account for an absent content element.
The notes section is now gone. PaceTextShouldBeProvides now contains a
proper superset of the instructions contained in PaceOptionalSummary.
Perhaps now we can get beyond discussing alleged incompatibilities.
- 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
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
- Sam Ruby
extual representation may suffer the same fate?
- Sam Ruby
ry element.
Incorporated. Thanks!
- Sam Ruby
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.
PaceC
ocument. As one of the status 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 the
cussion that occurred when that
particular proposal was brought before the working group?
- Sam Ruby
sdom of requiring unique IDs on entries. There may be
consensus that unique by source is sufficient.
- Sam Ruby
1 - 100 of 232 matches
Mail list logo
