will if it isn't
WebDAV-compatible, but everyone might decide to look the other way.
Robert Sayre
. They are not going
to get the namespace right at first, so they are going to add a div
element around the outside. However, this is not going to reflect what's
in MySQL.
Robert Sayre
[0] http://validator.w3.org/check?uri=http%3A%2F%2Ffranklinmint.fm
the problem.
Anne, Henri: thank you for missing the point.
Martin Duerst wrote:
However, this is not going to reflect what's in MySQL.
Does it need to? Could anybody except for you check?
Should anybody (including you) care? Is it part of conformance?
Yes. No. Yes. Yes.
Robert Sayre
+1
Robert Sayre
James M Snell wrote:
Robert Sayre wrote:
Yes or No: Is asking what capabilities existing XML-RPC protocols
provide is a productive way to set the limits of the Atom Protocol?
Of course not. I for one don't really give a rip what the existing
XML-RPC API's currently provide or don't
the chants. OMG ATOM DOESN'T
DO PODCASTING LOL
Robert Sayre
Tim Bray wrote:
On Feb 15, 2005, at 11:52 AM, Robert Sayre wrote:
PaceLinkEnclosure
A little bit of support, but with reservations.
DISPOSITION: A messy Pace and not enough support, close it.
You're kidding, right? I can already here the chants. OMG ATOM
DOESN'T DO PODCASTING LOL
Uh, we already
judgement to make something
accessible.
Also, I might be inadvertantly arguing for something similar to the
@profile proposals, but I hope not ;)
Robert Sayre
[0]
http://www.atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3.p.1
written so they get their
bearings. The difference between the two approaches is *huge* on, say, a
GPRS device.
A fuller approach has been discussed for syncing and such, and I can see
value in including the entire entries in that listing (which would
mirror getRecentPosts pretty well).
Robert
provide is a productive way to set the limits of the Atom Protocol? [1,2]
Secondly, I provided *two* use cases. What about link blogs?
Robert Sayre
[0] http://www.livejournal.com/doc/server/ljp.csp.xml-rpc.protocol.html
[1] http://blog.kung-foo.tv/archives/001228.php
[2] http://inessential.com/?comments
attribute value of
'alternate'.
http://www.atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3.p.1
Robert Sayre
be organized the way it is now. This is not a
gauntlet[0][1][2] Atom needs to run.
Robert Sayre
[0] http://weblogs.mozillazine.org/roadmap/archives/005632.html
[1]
http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0004/2004jun02.html#topic24.2
[2] http://www.w3.org/2004/04
after all.
Robert Sayre
-- It must be possible to serialize a complete collection of
entries using the Atom Format.
Robert Sayre
-1. Doesn't make sense or add value to the document.
Robert Sayre
Paul Hoffman wrote:
+1. It is a simple clarification that shows the intention without
restricting anyone.
+1. Agree in full.
Robert Sayre
Paul Hoffman wrote:
-1. Not core. The current text has a simple way of creating archives,
and extensions can be used to create more specialized archive formats.
-1 to the Pace. Agree in full.
Robert Sayre
+1. Our AD has told us how to write this section, so the Pace just adds
the regex, which I'm in favor of. Sam's suggestion at the end could
easily be accomodated with a sentence saying As a result, the date
values are valid according to [RFC3339], [XML-SCHEMA], and [w3cdtf].
Robert Sayre
+1. Says all that we need to without getting into HTML too deeply.
Robert Sayre
Some feel that since the atom:image could contain text, multiple
instances ought to be allowed for to support multilanguage.
These people are wrong. -1 to the Pace.
Robert Sayre
. Alright.
Robert Sayre
RFCs at the top of our document.
Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg12625.html
with this problem around Feb 21ish[0].
Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html
of arcane XML serialization mistakes in the course of
discussion, it's clear to me that Sam is right.
+1 to PaceXhtmlNamespaceDiv
Robert Sayre
guess I'd have to see some more
spec text, then. I'm not sure what Mark is proposing.
Robert Sayre
Looks like we forgot to write a formal Pace for removing the protocol
elements.
Proposed by Julian:
http://www.imc.org/atom-syntax/mail-archive/msg12887.html
+1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and
Underwood.
Robert Sayre
aren't supposed to matter to
Core Atom processors, why not put our money where our mouth is and
make profiles declare themselves in their own namespace?
Robert Sayre
James M Snell wrote:
Robert Sayre wrote:
I'm not sure they are that antagonistic, but I agree with Paul when he
says they could be added later. If profiles aren't supposed to matter to
Core Atom processors, why not put our money where our mouth is and
make profiles declare themselves
James M Snell wrote:
Further, the core spec
still does not expressly allow extensions to change the containment
requirements.
That's right.
Thus far, the only thing an extension can do is add new
types of namespace qualified metadata elements.
Yes.
Robert Sayre
/key
true/
keyread/key
true/
/dict
Also, Thunderbird uses them to compose its message-id. I could go on.
Robert Sayre
, including document order.
Extensions don't get to make demands on generic Atom processors.
Lots feeds will consist of entris with the same date, and lots of
aggregators will just show things in the order the SAX parser sent it.
Robert Sayre
the way to do it. Since you're
advocating versioning, what are your plans for versioning the state of
the feed itself? What if the title changes? It would be better to
archive a series of feed documents.
Robert Sayre
timestamps where some are lacking the timezone information.
I would tend to agree. Can we have that regex go in the Pace itself?
That would make the proposal pretty much editorial, since the set of
allowed timestamps would be the same (right?).
Robert Sayre
Norman Walsh wrote:
/ Robert Sayre [EMAIL PROTECTED] was heard to say:
| I would tend to agree. Can we have that regex go in the Pace itself?
The regex is in the pace.
I took the liberty of adding it to the proposal section.
Robert Sayre
Bob Wyman wrote:
Robert Sayre wrote:
Bob Wyman wrote:
As long as multiple instances/versions of an entry are permitted to
exist in a single atom document while sharing the same atom:id, the
current Atom document format provides a useable archive format.
This is clearly a non-starter
for ignoramus
apps.
BTW, if it weren't for the atrocious design error of banning recursive
feeds, we wouldn't even be having this argument. A feed would always
mean current status, while a series of them would mean stream.
Robert Sayre
it's a
gross hack. So, perhaps atom:archive shouldn't define anything besides
atom:entry.
Robert Sayre
to be atom:head, but it does need to be part
of the core.
Why?
Robert Sayre
: It's faster if you just say C++. Obviously,
these aren't going to happen. OK.
---
I think that about covers it.
Robert Sayre
than RFC 3339.
I propose that we change the spec to do so.
I agree. I was just writing a protocol implementation in Ruby On Rails
(CRUDs very fast, btw). When I got to the part on date formats, I used
xsd:dateTime code that was already done, figuring that's what everyone
else will do.
Robert
. How does it hurt interop to put an image in
an entry?
Robert Sayre
clients to keep separate records of entries with the same
id. We should probably be more worried about bad implementions totally
missing the point of identifiers, than about good implementations with
sophisticated notions of versioning and identifiers.
Robert Sayre
Tim Bray wrote:
I'm with Mnot on this one. Just because it uniquely identifies an
entry, that doesn't mean you can't have two versions of the same
entry in a feed. ... I don't see any reason for ruling them out in a
single feed.
Robert Sayre wrote:
We should probably be more worried about bad
of the current status of a set of entries, then it only
makes sense to include one entry per atom:id. I would argue the second
definition makes a lot more sense and accurately reflects real-world
usage, where even the RDF formats recommend against repeating rdf:about.
Robert Sayre
without making an unintentional pun. source-feed is fine. The section
on atom:head is totally confusing and bad--it's easier if you just do it
the way PubSub does it *right now*.
Robert Sayre
be
an if/else in the code). Btw, this sounds like it's going to work like
RDF/XML striping.
Yes, I wrote the initial feed in the RDF validator.
Robert Sayre
that they
each contributed to the entry?
For that matter, I wonder if the constraint makes sense for author.
Kind of, sort of, maybe.
That's a typo on my part. The Relax NG is correct.
Robert Sayre
friends), if not perhaps widely seen outside of
geekland. So I think I'm +1 on PaceAggregationDocument. (And I think
if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
I think you should wait for examples.
Robert Sayre
Tim Bray wrote:
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
http://groups-beta.google.com/group/bloggerDev
define some other document format? OPML will
do that just fine.
Robert Sayre
The atom:entry element represents an individual entry.
I really must find out more about this theology that allows one to
divine the precise nature of lists, data, metadata, items, containers,
and representations.
Robert Sayre
, so
there's no reason to leave it in.
Robert Sayre
Joe Gregorio wrote:
On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
10.1 HTML and XHTML Content
Text Constructs and atom:content allow the delivery of HTML and XHTML
into a client application. Many elements are considered 'unsafe' in that
they open clients to one or more
why the aspect ratio shouldn't be a MUST? Aren't
icons (on computers, anyway) pretty much universally 1:1?
LiveJournal images are square.
Robert Sayre
. So,
let's have the process take over.
Robert Sayre
excede anything we can expect, but
some aspects of the model would be extremely valuable to the format and
protocol, IMHO.
Robert Sayre
[0]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0
out a critical bug or missing feature in the format, and a
significant number of WG participants agree, we should miss our deadline
because we no longer have consensus on the *current draft*.
Robert Sayre
Tim Bray wrote:
On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote:
Currently, the format spec has a normative reference to the protocol
spec (and also defines elements for the service URIs, for instance,
atom:introspection).
I suggest this can and should be removed.
Agree.
Robert Sayre
Henri Sivonen wrote:
On Jan 31, 2005, at 00:53, Robert Sayre wrote:
I think this should come with the following URL:
http://www.oasis-open.org/committees/relax-ng/spec-20011203.html
I don't want to refer to OASIS's URLs.
Why not? Will ISO-Relax NG be available on the Web free of charge? Specs
Julian Reschke wrote:
Thanks for the feedback, Robert...
Robert Sayre wrote:
- rel attribute is missing
The rel attribute is optional and the relation is considered to be
alternate in that case.
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute
http://atompub.org
Bjoern Hoehrmann wrote:
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd
.
Robert Sayre
, snarky, slang-ridden
proceedings in English to declare consensus against them. So, I concur
with the chairs, even though the cost concerns me and IRIs are certain
to cause problems in the short-term.
Robert Sayre
to atom:entry that indicates whether it refers to
an instance of entry or another feed
4.) current draft (head in entry and all that)
5.) PaceAggregationDocument
Robert Sayre
and Perl suck equally. Ruby is surprisingly elegant when you get
to thinking about it.
OS X and Windows suck equally. Linux is surprisingly elegant when you
get to thinking about it.
Robert Sayre
Robert Sayre wrote:
4) Add a sentence saying something like Feeds or Entries
are identical if their IDs compare identical..
Seems obvious, but isn't stated anywhere.
No. Feeds/entries with the same id are different versions or
instances of a common ancestor. They are not the same.
Martin
that this was raised again. We went over and over on
the matter, and no one ever used them anyway.
Robert Sayre
this heavily already. One example is FeedBurner feeds that
incorporate Atom feeds. They know they can show the info element as an
explanation. Without a standard element, they will have to write 90%
similar code for every blogging vendor. It should be standardized.
Robert Sayre
on the matter, and no one ever used them anyway.
+1. I think it is important to include multiple translation in a single
feed.
I'm sorry, this was decided months ago. Why don't you go back and read
why it happened.
If we have multilple content elements, I propose that we rename it to
element.
Robert
available where one
consumer will only ever use half of the content is bad practice. Use two
resources. If we were looking for a way to make the bandwidth problem
much, much worse, this would be one way.
Robert Sayre
Sam Ruby wrote:
Robert Sayre wrote:
* 4.21 The atom:info Element -- If it's not considered meaningful
for processors, why does there need to be a standard element for it?
At the very least, some sort of information about its semantics
should be documented. My preference would be to drop
useful as shorthand for less technical
people. So, no change to the spec is necessary. I understand you are
looking for the spec to guide the validators behavior, but I don't think
it should.
Robert Sayre
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
I'll also note that this example is not valid. It does not contain
either a summary or content element.
Hmm. How do I do a linkblog with this restriction?
Robert Sayre
/thing
You cannot count on a positive or negative, and you are sloppy.
Robert Sayre
Julian Reschke wrote:
Robert Sayre wrote:
Um, the spec doesn't say you can. If the comparision is done with
URI.equals(), it will be positive. If it is done with
String.equals(), it will be negative. That text is a refelection of
reality.
http://atompub.org/2005/01/27/draft-ietf-atompub-format
?
If the validator does not look to the spec for guidance, where should
it look?
If somebody can answer my questions, I would appreciate it..
I think the spec should cover Atom documents identified with the Atom
media type. Other types are undefined.
Robert Sayre
Sam Ruby wrote:
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I suspect that once people see some examples, objections will surface
Sam Ruby wrote:
Robert Sayre wrote:
If I am conflating validity with media types, then so is the XML
specification.
I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for
an XML document to be valid if served with media type
Eric Scheid wrote:
On 31/1/05 6:17 AM, Robert Sayre [EMAIL PROTECTED] wrote:
Instances of Identity constructs can be compared to determine whether
an entry or feed is the same as one seen before. Processors MUST
compare Identity constructs on a character-by-character basis in a
case-sensitive
Eric Scheid wrote:
On 31/1/05 10:16 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I agree with you in principle, but I find the current text unrealistic.
It's just fodder for stupid arguments.
what? and Atom Processors MAY perform additional scheme-specific
comparisions won't lead to stupid
Sam Ruby wrote:
Robert Sayre wrote:
Sam Ruby wrote:
Robert, can you take a stab at updating section 1.2 for this Pace?
Yes, but the Pace is complete without it.
It would be much easier to discuss the pace with an example.
I gather that a format-05 compatible feed, thus:
I suspect that once
Graham wrote:
On 31 Jan 2005, at 12:16 am, Robert Sayre wrote:
Graham wrote:
Yeah, that's a horrible loose end to leave hanging.
No, it isn't. URI comparison is not our problem, and what our spec
says about it doesn't matter a bit.
Yes it is times one million. Ha ha I win et cetera
Defining
Graham wrote:
On 31 Jan 2005, at 12:43 am, 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
dereferenced. Secondly, I fail to see how dereferencing a URI
would cause interop problems.
Robert Sayre
RFCs that I'd rather not mess with.
Robert Sayre
' has morphed
into, than I'd rather see it dropped.
Thanks for bringing up this problem.
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Yay! Let's drop atom:host.
Robert Sayre
(mI), so the authors of those Paces should take a look.
Robert Sayre
should be normatively defined w/ XSLT. It meets the
cross-platform requirements of the IETF and is unambiguous. Of course,
it had better be really good! If someone wants to optimize with a SAX
version, they still can.
Robert Sayre
with it is not on,
especially when they're this drastic.
Agree w/ Graham. We don't know what kind of relationship the publisher
and consumer have.
I would strike all the details on HTML, leave the first paragraph, and
refer to the security sections of RFC 2854 and HTML 4.01.
Robert Sayre
to find such a reference myself. Maybe someone else has better
google-fu than me.
I guess the question is whether we can and should outline HTML security
issues.
I don't think we can or should.
Robert Sayre
all,
the catch phrase is not Cool IRIs Don't Change. What can we do
minimize confusion?
Robert Sayre
between ASCII and
UTF-8).
-1 on the pace.
-1 as well. Allowing people to assert they are using a subset of what's
available is not a design error.
Graham
(PS Are line breaks in Text mode honored?)
The current text says whitespace collapsing is allowed.
Robert Sayre
.
Robert Sayre
Henri Sivonen wrote:
On Jan 27, 2005, at 22:39, Robert Sayre wrote:
Anne van Kesteren wrote:
So I can not include MathML in the TITLE of my weblog? I do not see
why this restriction is necessary.
Nope. Can any aggregator display it?
I expect Gecko-based aggregators to support MathML eventually
-formed XML.
So, Atom documents are well-formed XML identified with the Atom media
type. The specification doesn't talk about other media types or
ill-formed XML documents. Is there something more we can add to the
specification? I don't think PaceMustBeWellFormed is it.
Robert Sayre
Walter Underwood wrote:
--On Tuesday, January 25, 2005 03:39:13 PM -0500 Robert Sayre
[EMAIL PROTECTED] wrote:
I'm very -1 on this, since it makes the definition of the Atom format
an HTTP message, rather than an XML document.
On top of that, most of the Pace is babysitting. To the Guide
wrapped up in HTTP, pedantic, and
incorrect in numerous ways.
Robert Sayre
in front of you.
Bring this issue up again after the next draft if you still think it's
worthwhile to embark on a campaign to rename an attribute.
Robert Sayre
reading it,
imitate the examples, and end up with similar syntax anyway. People
who take the time to read the spec are even less likely to do something
ugly. That mostly leaves elements from existing vocabularies.
Robert Sayre
suspect
Graham will prefer it.
We can pick up the pace to incorporate wording and nitpick changes.
Robert Sayre
401 - 500 of 514 matches
Mail list logo
