of implementations seems to agree.
I agree that it is important to distinguish between feeds and feed
documents, and this is why I think that feed level inheritance of
licenses should be dropped as it is incompatible with Atom.
Monday, December 18, 2006, 10:22:17 PM, Bob Wyman wrote:
On 12/17/06, David
Thursday, December 14, 2006, 9:04:00 AM, Henri Sivonen wrote:
On Dec 13, 2006, at 17:51, Mark Baker wrote:
But
given that an alternative exists which shouldn't break those servers,
why not use it when there's no apparent downside?
The downside is that implementations that (quite
I've always interpreted a kind of inheritance relationship between
MIME types.
It's never wrong to label an Excel file, an XML document, or an Atom
Feed as application/octet-stream, because all of those types ARE
octet-streams. It is just not as helpful as it could be.
Likewise, it is never
I don't have much experience with bidi. I've been having a quick read
up on it, and there seem to be the following features. Correct me if
I’m wrong.
a) Unicode implicitly supports bidi. Write a span containing Hebrew
characters, and it will be laid out right to left. We don’t need to do
It is hard to discuss the impacts without knowing what status we are
trying to achieve with this and any other proposed changes to Atom.
Are we planning on changing the Atom namespace?
Adding inheritable attributes seems like a breaking to change.
Existing compliant implementations will
Tuesday, October 3, 2006, 12:20:01 AM, James Snell wrote:
I think the suggestion of adding a dir attribute is a very good idea.
The great thing is that it can be done without any significant backwards
compatibility concerns. The definition of the attribute is simple enough:
Tuesday, October 3, 2006, 1:55:31 AM, I wrote:
As we depend on Unicode, then we can't really stop people from using
Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even
CSS bidi controls. I think we should think carefully before we
introduce yet another method for bidi
Wednesday, September 6, 2006, 11:38:13 AM, you wrote:
So, here's the proposal:
- Use link rel=license/ for entry licenses -- either on the feed
level, setting a default analogous to what atom:rights does, or on
the element level.
I think that there are data modelling issues with this
Wednesday, July 26, 2006, 8:33:55 PM, James M Snell wrote:
Now imagine that we start to apply machine translation to entries, so
that we can say, give me all entries, but translate them to French, or
English, etc. Would that be best done using conneg or separate URIs?
I'd go for seperate
Wednesday, June 28, 2006, 1:22:00 PM, James Snell wrote:
Hiding the div completely from users of Abdera would mean
potentially losing important data (e.g. the div may contain an xml:lang
or xml:base)
I don't think that the div should contain an xml:base, because it
isn't valid to use
Wednesday, June 28, 2006, 9:55:29 PM, James Snell wrote:
David,
you're right, ideally the xhtml container div would be nothing but the
div, but if it's not, we still need to be prepared to handle it. Silent
data loss sucks, if it's silly data :-)
I'm just looking at it from the
Friday, May 26, 2006, 2:31:40 PM, Andreas Sewe wrote:
But the test cases should IMHO not test whether ALTERNATE works, since
it should not, but whether
http://www.iana.org/assignments/relation/alternate; does. But then
again my reading of 4.2.7.2 might be wrong.
I agree. [EMAIL
Friday, May 26, 2006, 6:57:03 PM, Robert Sayre wrote:
On 5/26/06, James Holderness [EMAIL PROTECTED] wrote:
Logically I would assume the simple string comparison in section 5.3.1 of
RFC3987, but I was hoping this would be documented somewhere more
explicitly. An atom:id is an IRI too, but
Tuesday, May 23, 2006, 10:31:37 PM, Tim Bray wrote:
I would say that furious debates about elements-vs-attributes have
been going on since the dawn of XML in 1998, but that would be
untrue; they've been going on since the dawn of XML's precursor SGML
in 1986. They have never led anywhere.
Friday, May 19, 2006, 1:40:43 AM, Lisa Dusseault wrote:
I've been trying to understand if there's a technical problem with
the draft's chosen placement of the attributes and the best case
I've seen is that that location is technically disallowed by
RFC4287 , an assertion which is disputed
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
That doesn't accurately state my problem with FTE. My concern is more
general
Tuesday, May 16, 2006, 11:18:04 AM, Sylvain Hellegouarch wrote:
Hi everyone,
These days It seems that when UAs request a server to check if a feed has
changed the server responds with either an HTTP 304 Not Modified status
code or by returning the updated feed.
It looks to me as a
Friday, May 5, 2006, 4:05:15 AM, Tim Bray wrote:
Give me a break, we're in the first *days* of something that will be
used for at least decades. Todays' APIs will have a vanishingly-
small lifespan in comparison
The issue isn't that an implementation is at fault. The issue is that
a
Friday, May 5, 2006, 12:20:25 AM, A. Pagaltzis wrote:
* M. David Peterson [EMAIL PROTECTED] [2006-05-04 23:30]:
Or is something like this simply inviting WAY TOO MANY little
things to find justification to plug up the collective inbox of
the community members?
I don’t know. So far during
Tuesday, May 2, 2006, 10:06:51 PM, James Holderness wrote:
Just looking at that example, it seems to me that an aggregator that
implements Microsoft's simple list extensions would get a full-featured
representation of that feed without having to know anything at all about
feed rank and
Monday, May 1, 2006, 8:40:57 PM, James Snell wrote:
I'm wondering if it would make sense to have a single common type
scheme that could be used consistently across implementations.
random thoughts
Type seems a bit vague, this seems to be mainly about describing how
an entry should be
Tuesday, May 2, 2006, 9:12:56 PM, James Snell wrote:
Does your implementation properly handle the following (contrived) example:
entry xml:base=http://example.org/foo/bar;
...
link href=../comments.xml rel=replies /
thr:replies href=http://EXAMPLE.org:80/foo/bar/../comments.xml; ... /
Saturday, April 22, 2006, 1:53:26 AM, James M Snell wrote:
So this is what I've got:
count = element thr:count {
attribute xml:base { atomUri }?,
attribute ref { atomUri }?,
attribute updated { date-time }?,
( nonNegativeInteger )
}
I think that is ok.
Aristotle's
Thursday, April 13, 2006, 6:11:32 AM, Eric Scheid wrote:
atom:link beats thr:replies on the basis that I don't need to understand
what replies are to discover that there is a link from this thing to that
thing.
atom processors know what atom:link is, but it wouldn't know what to do with
Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote:
c. Create a new replies extension element
thr:replies href=...
type=...
hreflang=...
title=...
count=...
when=... /
-0.5, it *is* a link
Wednesday, April 12, 2006, 1:29:00 PM, A. Pagaltzis wrote:
* David Powell [EMAIL PROTECTED] [2006-04-12 13:40]:
Reasonable implementations will probably just store the latest
versions of feed and entry metadata, something like this:
Of course, what they *should* do is use `atom:source` so
Tuesday, April 11, 2006, 9:20:32 PM, James M Snell wrote:
I also added a new warning for implementors: Implementors should note
that while the Atom Syndication Format does not forbid the inclusion of
namespaced extension attributes on the Atom link element, neither does
is explicitly allow
Friday, March 31, 2006, 3:31:12 AM, A. Pagaltzis wrote:
In that scenario, either the tag soup from the other feeds must
be fixed up so the view can be rendered as XHTML (which supports
xml:base in content)
XHTML 1.0 doesn't support xml:base does it? As I understand it, only
specs that say
Friday, March 31, 2006, 4:34:48 AM, you wrote:
The escaped HTML content contained within the content element that
David was originally concerned with is more than likely a copy of
all or part of the elements and content contained inside the body
tag of the external document referenced by an
Friday, March 31, 2006, 11:02:18 AM, Sean Lyndersay wrote:
I haven't looked in detail at how IE does on the xml:base
comformance tests, since the current beta has no support for
xml:base. In light of that fact, I'm glad we failed outright instead
of halfway; halfway would have been weird
Friday, March 24, 2006, 3:28:02 AM, James Snell wrote:
I believe the concern is over the thr:count and thr:when attributes for
the replies link relation, both of which are optional, and both of which
provide what I consider to be extra information. In other words, it's
ok if an
Thursday, March 23, 2006, 4:57:11 PM, you wrote:
On 24/3/06 3:21 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
authorname![CDATA[Bertrand Cafeacute;]]/name/author
Even if it was HTML you couldn't really use the entity, could you? I think
you have to use a character reference or the
xml:base applies to type=xhtml content, but I'm not sure whether it
is supposed to apply to escaped type=html content? I reckon that it
does.
Anybody came across this? Any opinions?
--
Dave
Thursday, March 23, 2006, 9:39:09 PM, James M Snell wrote:
Just wanted to follow through on this for everyone. Given that there
are vendors getting ready to ship code based on the current rev of the
spec, I'm *not* going to rename the id attribute to ref. Yes, I
know that id is confusing
Wednesday, March 22, 2006, 5:13:05 AM, M. David Peterson wrote:
Hey Folks,
With yesterdays build release of IE7, it seemed appropriate to run
a quick inventory check to see where things stand in regards to the
derived MS/RSS conversion of a fairly element/attribute usage
heavy Atom
Thursday, March 16, 2006, 7:31:08 PM, you wrote:
David Powell wrote:
Not sure if this is a known bug, but I just noticed that the RelaxNG
grammar doesn't accept atomCommonAttributes (eg xml:lang) on the
atom:name and atom:uri and atom:email elements used within
Person constructs.
Did you
Wednesday, March 15, 2006, 3:21:08 AM, Martin Duerst wrote:
For atom:uri and atom:email at least, not having xml:lang may
be seen as a feature.
The spec says that Any element defined by this specification MAY have
an xml:lang attribute. We chose to limit the effects of xml:lang,
rather than
Not sure if this is a known bug, but I just noticed that the RelaxNG
grammar doesn't accept atomCommonAttributes (eg xml:lang) on the
atom:name and atom:uri and atom:email elements used within
Person constructs.
--
Dave
Friday, March 10, 2006, 5:44:21 PM, you wrote:
Are linked feeds required to have unique atom:id values? Or, are they
required to have the same atom:id values?
Thoughts?
The history spec frequently uses the phrase the feed in the
singular, this implies to me that the id's of the feeds must
Hi Sean,
I've been testing IE7 beta 2's support for Atom, with the following
test feed:
http://djpowell.net/atom-test/hardfeed/feed/hard-feed.atom
Also here for easier viewing in IE7
http://djpowell.net/atom-test/hardfeed/feed/hard-feed.xml
Here are the problems that I have found:
01.
Thursday, February 23, 2006, 6:37:50 AM, you wrote:
Does someone who has access to an MSFT system care to take a
look at this?
I have been playing with IE7, and it is interesting to see what
happens when you click on a feed and view source.
If the feed hasn't been subscribed to, you just
Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote:
[CC'ing atom-syntax]
2006/2/1, David Powell [EMAIL PROTECTED]:
Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote:
Entries in an Atom feed can share the same atom:id but their
atom:updated values should
Thursday, January 19, 2006, 11:17:38 AM, Graham Parks wrote:
The correct thing to do is to pick the one provided by default by the
server when no content negotiation occurs. eg:
content type=image/png href=http://www.example.com/img; /
Possibly, but that solution isn't perfect. There is
Tuesday, January 17, 2006, 9:48:22 PM, I wrote:
Eg: perhaps the publisher is attempting to send a HTML document that
they saved in Word, full of CSS styles, that is intended for printing. [*]
[*] Off-topic rant:
Let's hope that the user doesn't attempt to publish their document
as .mhtml,
Tuesday, January 17, 2006, 8:39:54 PM, James Holderness wrote:
This has got nothing to do with second-guessing. Just pretend for a moment
that there was no such thing as the xhtml type. Now the question is what
is the correct way for an aggregator to display an application/xhtml+xml
From 4.2.10:
If an atom:entry element does not contain an atom:rights element,
then the atom:rights element of the containing atom:feed element, if
present, is considered to apply to the entry.
Is there a reason that this paragraph excludes inheritance from
atom:source?
Section
Quoting Lindsley Brett-ABL001 [EMAIL PROTECTED]:
I have raised this question a few times. The issue is separating the
resource from its representation. A single resource (e.g. a football
game) may have many representations (audio only, slide show,
audio/video, etc.). We would need a more
Monday, September 12, 2005, 5:55:20 PM, James M Snell wrote:
I've updated the draft that defines an extension that can be used to
indicate that the order of entries within a Feed should be considered
significant.
How will this interact with the sliding-window/feed-history
interpretation
Sunday, August 21, 2005, 8:46:54 PM, Paul Hoffman wrote:
At 7:24 PM +0100 8/21/05, Peter Robinson wrote:
I do something similar, intending it to mean the location of the items
described by this feed (when there is a single location).
Ah, I had missed that. This leads to a question for the
Wednesday, August 10, 2005, 11:33:46 PM, Robert Sayre wrote:
On 8/10/05, David Powell [EMAIL PROTECTED] wrote:
I think that it is pretty clear, but as Tim disagrees, I think that
this is a good indication that we need clarification.
I think it's good indication that you've argued
I said:
I might have misinterpreted your comment, but I'm arguing with Tim for
saying that SEE's CAN contain relative refs and no clarifification is
needed, and with you for saying that SEE's CANNOT contain relative
refs and no clarification is needed. There's a word for that :)
I
I still believe that relative URIs shouldn't exist in Simple Extension
constructs [1]. I think that the lack of rationale for their being 2-3
classes of extension construct is proving to be harmful.
Prior to the introduction of Section 6, Atom pretty much said you can
include any foreign
Tuesday, August 9, 2005, 11:22:14 PM, Robert Sayre wrote:
What are we going to do, outlaw strings that happen to look like
relative references?
No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must
Quoting Tim Bray [EMAIL PROTECTED]:
Right, but anyone who reads a simple extension out of an Atom feed
and finds something they consider to be a relative URI reference, and
wants to absolutize the reference, either uses the base URI as
established by xml:base, or they are wrong. -Tim
The intention of Simple Extension Elements is to provide a
simple class of extension that is part of the Atom model, and can
therefore be preserved end-to-end by implementions via publishing
clients, servers, databases, and aggregators.
We say that Simple Extension Elements are not language
draft-11:
This specification does not place any restrictions on what elements
may be used as Metadata Extensions, but the RelaxNG grammar
explicitly excludes elements in the Atom namespace. The Atom
namespace is reserved for future forwards-compatable revisions of
Atom.
I'm not sure I
Sunday, July 31, 2005, 4:19:40 PM, you wrote:
I see, thanks for the clarification.
(I guess atom never intended to allow free -as in speech *and* in
beer- data mixing anyway, but another namespace would perhaps have
facilitated the inclusion of atom data in existing rdf tools.)
I would
Sunday, July 31, 2005, 4:32:11 PM, Graham wrote:
On 31 Jul 2005, at 4:01 pm, James Cerra wrote:
That's apparently what libxml does. As you can see, with Atom's
namespace it
is a mess. It is also a mess with XHTML's namespace, XSLT's
namespace, and
most document-oriented namespaces.
Sunday, July 31, 2005, 4:47:44 PM, A. Pagaltzis wrote:
Strictly speaking, per Extensions To the Atom Vocabulary (sec.
6.2), an Atom processor must treat the nested link as it would
treat any other Structured Extension Element (sec. 6.4.2).
Only child elements of atom:entry, atom:feed, and
Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote:
link rel=in-reply-to ...
link rel=in-reply-to-feed ... /
/link
I'm not at all keen on extending the link element in this way. Atom
Publishing Servers that don't know about this extension that receive
an entry containing
Sunday, July 31, 2005, 1:09:44 AM, I wrote:
I don't believe that atom:link _isn't_ usefully extensible other than by
er, that should be is
--
Dave
Sunday, July 24, 2005, 9:39:53 AM, Danny Ayers wrote:
David Powell's full and fairly verbose RDF schema, again I think it's
an Atom-specific vocab :
http://djpowell.net/atomrdf/0.1/
Dates from 2005-03-22, covers draft-05.
it can be viewed through a nifty little styled-TriX converter:
Sorry for the pedantry, but I'm trying to update my Atom/RDF thing, so
pedantry is required...
The inheritance rules for atom:rights, are different to the ones for
atom:author. Is this intentional? Are they supposed to be treated
differently?
See:
If an atom:entry element does not contain
Tuesday, July 19, 2005, 12:44:51 AM, A. Pagaltzis wrote:
You misunderstood what I said. The point is that regardless of
how the base URI is determined (whether it is embedded in content
or otherwise), it *means* that the content it applies to was
actually found at the base URI. It’s not
Tuesday, July 12, 2005, 12:29:58 AM, James M Snell wrote:
The third is a non-RDF adaptation of the Creative Commons RSS 1.0 Module
that uses the Atom link element and provides a machine readable license
for entries and feeds. It is described @
http://www.snellspace.com/wp/?p=184.
feed
It's been raised before [1] [2], but can we clarify whether a MIME
type in atom:content etc. can contain parameters or not?
MIME is a bit vague about the definition of what a mime type is, and
historically applications have been tripped up by unexpected MIME
parameters.
Can we add something
Tuesday, July 5, 2005, 5:09:40 PM, Paul Hoffman wrote:
At 11:58 AM -0400 7/5/05, Bob Wyman wrote:
Could we at least put in a sentence that states that including a
source element in signed entries is recommended? The implementer's guide
would then expand on that with more detail,
Sunday, June 19, 2005, 5:43:36 AM, Antone Roundy wrote:
On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote:
Atom 0.3 multiparts forced a dubious and complex processing model on
everyone wanting to process Atom documents. This problem was solved by
their removal in the 03 to 07
Sunday, June 19, 2005, 5:07:01 AM, you wrote:
The prohibition of composite types in the 08 draft (made many months
later)
Um, no. One of the drafts reworded the requirement in terms of the new
MIME draft. Previously, the draft cited RFC2045's discrete type.
From format-03:
Failing
Friday, June 17, 2005, 6:14:38 PM, you wrote:
Uh, has Mark spotted a dumb bug here that we should fix? Do we care
if *remote* content is of a composite MIME type? My feeling was that
we ruled out composite types in *local* content, for fairly obvious
reasons. The fix is obvious, in
Saturday, June 18, 2005, 1:40:52 PM, Sam Ruby wrote:
Can somebody give me a link to where we discussed the requirement that
atom:content MUST NOT contain a composite type? I've tried searching my
archive but I couldn't find anything at all. The change was introduced
in draft-08.
I can't
Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:
My feeling was that we ruled out composite types in *local* content
[...]
I'm still looking, but my suspicion is that we never did rule them
out, and that this restriction crept in during some editorial
rephrasing.
[...] for fairly obvious
Apologies for the rubbish timing, but I've been reviewing section 6, and found a
number of problems.
Firstly, there are some mismatches between the RelaxNG grammar and the
specification text. I know that the RelaxNG grammar isn't normative; but this
doesn't mean that it can be contradictory:
Thursday, June 9, 2005, 5:51:57 PM, Tim Bray wrote:
On Jun 9, 2005, at 9:22 AM, David Powell wrote:
Firstly, there are some mismatches between the RelaxNG grammar and the
specification text. I know that the RelaxNG grammar isn't
normative; but this
doesn't mean that it can
Friday, June 10, 2005, 1:03:41 AM, Paul Hoffman wrote:
*All* reworking is not acceptable now.
[...]
There is a large difference between suggesting a bunch of reworking
and pointing out specific ambiguities. Please do the latter if you
find them.
Yes, I understand. In my previous mail
Quoting Thomas Broyer [EMAIL PROTECTED]:
The problem come when I use a plain flowed text and can then omit the
type attribute:
ext:bylineBy Thomas Broyer and al./ext:byline
My extension becomes a Simple Extension Element when processed by an Atom
Processor, and an Atom Processor having some
Tuesday, May 24, 2005, 5:26:39 PM, you wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
Friday, May 27, 2005, 7:18:40 PM, Eric Scheid wrote:
On 27/5/05 4:49 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
Replace format-08 with protocol-04 and you get it ;o)
http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt
except I've been getting format-nn from
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
But then 6.3 goes on to explain how to process it.
This sounds like a contradiction?
No, why?
Ok, I'd interpreted ignoring it to be processing it, as opposed to
failing. I'll concede that I misinterpreted that.
Say I am an Atom
Thursday, May 26, 2005, 11:16:05 PM, Thomas Broyer wrote:
David Powell wrote:
Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote:
6.2 deals with the Atom vocabulary, which is the markup in the Atom
namespace or un prefixed attributes on Atom-namespaced elements (this is
my
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
On May 25, 2005, at 1:40 PM, David Powell wrote:
What is section 6.3 unknown foreign markup for?
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion
Section 6.4:
The RNGs in this section require Extension Elements to be in a
namespace that isn't the Atom namespace. This requirement is missing
from the text.
Just a note:
This proposal doesn't rehash the
extensions -- Atom NS and unprefixed attributes thread [1], because it
only applies
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion. The point
is, either software knows what to do with an extension and does it,
or if not it's not allowed to
Tuesday, May 24, 2005, 9:22:29 AM, Eric Scheid wrote:
4.2.9 The atom:link Element
The atom:link element is an empty element that defines a reference from an
entry or feed to a Web resource.
Subject: Re: extension elements inside link elements?
did we want to prevent expressions like
Section 6.4:
The RNGs in this section require Extension Elements to be in a
namespace that isn't the Atom namespace. This requirement is missing
from the text.
Proposal
Add to section 6.4.1:
A Simple Extension Element MUST be namespace-qualified. The element
MUST be defined
Tuesday, May 24, 2005, 8:24:16 PM, Graham wrote:
On 24 May 2005, at 7:08 pm, David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style unknown foreign markup.
Unless there's a memo I missed, extensions are a subset
Tuesday, May 24, 2005, 7:50:13 PM, Thomas Broyer wrote:
David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point.
Could you explain why?
The following are extension points:
* Adding additional metadata to atom:feed by using Section 6.4
Extension
Sunday, May 22, 2005, 9:53:23 PM, Robert Sayre wrote:
The draft hasn't changed for more than a month, while Tim and Paul
have been last-calling this thing for months now, and very little of
substance has transpired since then. The document has been quite
stable since March 12th, when
Monday, May 23, 2005, 9:20:07 PM, Karl Dubost wrote:
Hi,
I will use the HTML version
http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http://
ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub-
format-08.txt
Only the text version is normative, but the editor
Monday, May 23, 2005, 6:18:53 AM, Roger B wrote:
I'm asking you specifically because you seem to be approaching your
argument in a reasonable tone and fashion. My apologies if I'm
pestering.
No apologies required, I welcome any useful criticism.
Near as I can tell, folks have modification
Sunday, May 22, 2005, 2:08:57 AM, Tim Bray wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
Sunday, May 22, 2005, 3:36:05 AM, Tim Bray wrote:
Summary: David Powell fails to materially address any of the three
fatal flaws I pointed out in the notion of atom:modified. I remain
firmly at -1.
Tim, thanks for taking the time to make specific points discuss this
in detail, despite
I thought it would be useful to give a use-case for
PaceAllowDuplicateIdsWithModified, so that arguments about the
validity of the use-case don't get mixed up with arguments about the
mechanics of the proposal.
The scenario is that an Atom publishing server wishes to allow
publishers to
I am concerned that the requirement:
atom:feed elements MUST contain exactly one atom:author element,
UNLESS all of the atom:feed element's child atom:entry elements
contain an atom:author element.
...suggests that some sort of inheritance goes on, but such a
mechanism isn't obvious and
Sunday, May 22, 2005, 10:22:24 AM, you wrote:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of XHTML? (I
really dislike this combined construct by the way.)
You can, but you would have to embed a full XHTML document, including
html and body elements.
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote:
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
comment from Robert in there saying that inheritance needed
explaining, but I can't see where this issue was resolved.
Oops. Here's the discussion:
http://www.imc.org/atom-syntax/mail
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote:
Besides, no one indicated they were unhappy with that text in WG last
call or IETF last call.
Sorry, I was too busy reviewing the 23 additional Paces that were
proposed during IETF Last-Call to have time to sufficiently review the
Sunday, May 22, 2005, 10:25:29 PM, Robert Sayre wrote:
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
I think that the current text is very misleading. The fact that at one
point inheritance has been condoned or suggested by previous drafts
(including the widely implemented pre-IETF
Monday, May 23, 2005, 12:20:21 AM, Bob Wyman wrote:
Tim Bray wrote:
The intent seems pretty clear; entry-level overrides source-level
overrides feed-level, but it seems like we should say that.
Anybody think this is anything more than an editorial change? -Tim
I believe that this
Saturday, May 21, 2005, 4:26:13 AM, Roger B. wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
1 - 100 of 160 matches
Mail list logo
