On Aug 17, 2005, at 4:10 AM, Henry Story wrote:
Yes. I agree the problem also exists for complex extensions. My
question is the following:
How can a parser that parses atom and unknown extensions, know when
to apply the xml base to
an extension element automatically?
It can't.
Anyway t
On 17 Aug 2005, at 00:14, Mark Nottingham wrote:
On 16/08/2005, at 3:05 PM, Robert Sayre wrote:
I suggested writing the next tag like this:
http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">
That's what I would do, too. Not my spec, though. Mainly so I could
Mark Nottingham wrote:
> For that matter, if Henry's interpretation were correct, the element
> could be
>
>./archives/archive1.atom
>
> And Atom processors would magically know that XML Base applies to the
> URI therein. It's the magic that I object to; inferring the
> applicability of conte
Tuesday, August 16, 2005, 11:14:42 PM, Mark Nottingham wrote:
> E.g., what if I want to have an optional attribute on an empty
> element? Is it "simple" or "complex"?
FYI: The first draft of the proposal used an atom:notation="structured"
attribute on the extension to indicate the extension cla
On 16/08/2005, at 3:05 PM, Robert Sayre wrote:
I suggested writing the next tag like this:
http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">
That's what I would do, too. Not my spec, though. Mainly so I could
put a title in that said "Entries from August" or wh
On 8/16/05, Henry Story <[EMAIL PROTECTED]> wrote:
> An application that does not know your extension cannot know that the
> text inside
> your extension is to be interpreted as a relative uri. So what you
> are saying is
> that any application that wants to process atom with extension
> elements
On 16 Aug 2005, at 21:50, Robert Sayre wrote:
On 8/16/05, Henry Story <[EMAIL PROTECTED]> wrote:
On 16 Aug 2005, at 21:00, Mark Nottingham wrote:
I very much disagree; relative references should be allowable in
simple extensions, and in fact the rationale that Tim gives is the
reasoning I ass
On 8/16/05, David Powell <[EMAIL PROTECTED]> wrote:
> The reason for there
> being two classes of extensions was to reduce this burden, so that
> implementations based on RDBMS, RDF, or whatever can process a common
> class of unknown extensions generically. The burden of requiring the
> lang and
Tuesday, August 16, 2005, 8:00:55 PM, Mark Nottingham wrote:
> I very much disagree; relative references should be allowable in
> simple extensions, and in fact the rationale that Tim gives is the
> reasoning I assumed regarding Atom extensions; if I had known that
> the division between s
On 8/16/05, Henry Story <[EMAIL PROTECTED]> wrote:
>
>
> On 16 Aug 2005, at 21:00, Mark Nottingham wrote:
> >
> > I very much disagree; relative references should be allowable in
> > simple extensions, and in fact the rationale that Tim gives is the
> > reasoning I assumed regarding Atom extensi
/next"; href="./
archives/archive1.atom">
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html
On 15 Aug 2005, at 22:31, Mark Nottingham wrote:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-a
On 16/08/2005, at 9:17 AM, Stefan Eissing wrote:
Ch. 5 similar: "MUST occur unless". If the document is an
archive there are only 2 possiblities: either fh:prev is there or
not. If not it will always "terminate" the archive list, won't
it? You seem to have a (server-side) model in mind wh
tory/1.0/next"; href="./
archives/archive1.atom">
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html
On 15 Aug 2005, at 22:31, Mark Nottingham wrote:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-no
quot;>
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html
On 15 Aug 2005, at 22:31, Mark Nottingham wrote:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-03.txt
Significant changes in th
Am 16.08.2005 um 17:42 schrieb Mark Nottingham:
On 16/08/2005, at 1:27 AM, Stefan Eissing wrote:
[...]
Ch. 5 similar: "MUST occur unless". If the document is an archive
there are only 2 possiblities: either fh:prev is there or not. If not
it will always "terminate" the archive list, won'
On 16/08/2005, at 1:27 AM, Stefan Eissing wrote:
Ch 4: Different use of MAY and SHOULD when compared to Ch. 3.:
"fh:stateful ...MAY occur" vs. "fh:archive...SHOULD occur..." On
third read i think i know how you mean it. But it is a circular
definition nevertheless.
I agree that there's
On 16 Aug 2005, at 02:19, Mark Nottingham wrote:
On 15/08/2005, at 5:09 PM, Robert Sayre wrote:
I'm interested in getting things working,
not playing the syndication format advocacy game.
Not sure how feed-history will work without a unique id.
? Sorry, you lost me there.
Yes. If you
Am 15.08.2005 um 22:31 schrieb Mark Nottingham:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-03.txt
Ch 4. Typo: remove period of first sentence
Ch 4: Different use of MAY and SHOULD when compared to Ch. 3
On 15/08/2005, at 5:09 PM, Robert Sayre wrote:
I'm interested in getting things working,
not playing the syndication format advocacy game.
Not sure how feed-history will work without a unique id.
? Sorry, you lost me there.
There's a difference between promoting multiple syndication form
On 8/15/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> On 15/08/2005, at 4:28 PM, Robert Sayre wrote:
> > Why is it desirable to promote mulitple syndication formats?
> > Practically any RSS2 extension would be ok in Atom, and any Atom
> > element would be legal in RSS2. If feed-history used ato
On 15/08/2005, at 4:28 PM, Robert Sayre wrote:
Why is it desirable to promote mulitple syndication formats?
Practically any RSS2 extension would be ok in Atom, and any Atom
element would be legal in RSS2. If feed-history used atom:link, it
would get xml:base processing and link descriptions "for
On 8/15/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> Draft -03 of feed history is now available, at:
>http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
> history-03.txt
>From <http://www.mnot.net/blog/2005/08/15/feed_history>::
"I re
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-03.txt
Significant changes in this revision include:
- add fh:archive element, to indicate that an entry is an archive
- allow subscription feed to omit fh:stateful
23 matches
Mail list logo
