Re: Feed History -03

[David Powell]

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 class which
avoided that problem, but I think it was considered to be too crufty.

-- 
Dave

Re: Feed History -03

[Mark Nottingham]

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 whatever.


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 context based on the presence or absence of other  
markup isn't good practice, and will lead to practical problems.  
E.g., what if I want to have an optional attribute on an empty  
element? Is it "simple" or "complex"?


This interpretation of extensions seems very fragile to me.

--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Robert Sayre]

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 has to keep
> the full context of the document in which they found the extension
> element, 

No, Henry, that's not what I'm saying. I'm saying you do have to keep
the Base URI of an atom:entry or atom:feed around, for a variety of
reasons. The app should keep the extension text as it was entered.

> 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 whatever.

Robert Sayre

Re: Feed History -03

[Henry Story]

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 assumed regarding Atom extensions; if I had known that
the division between simple and complex extensions would be used to
justify a constraint on the use of context in simple extensions, I
would have objected to it.


The problem is that readers of your xml that wish to store your data
in some form other than xml (relational database, triple store,
object oriented database, prolog database,...), and that may
not at the time of consumption know about your extension will  save
the content in text, which is all the spec says they should do. Since
they don't at the time know the meaning of fh:prev and
in particular that it should contain a URI  they can't save the
absolute URI it represents.
All they will be able to save is relative uri which will be
meaningless if the context of the
original document is lost.


The app should store the relative URI, and it shouldn't lose the  
context.


relative URI? The application we are speaking about knows nothing of  
a relative
uri. All you have inside your Simple Extension Element is text! See  
the spec 6.4.1.


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 has to keep
the full context of the document in which they found the extension  
element, even if
the document is a 100s of Megabytes long, and even if there is only  
one extension
element inside of it!  Or take the case of code that wants to place  
the feed inside
some other xml, which has a base element. What is it to do when it  
finds an extension

element it does not understand?




If you're using something like RDF to model feeds, you already have
a number of context-related issues to work through, this isn't an
extra burden.



The point of making extensions is that they should be interpretable
or at least in part useable
by parties that don't understand the extension.



It still is.


No they are not! See the 2 examples above.


This is a question of the Atom spec saying that the content of a
simple extension element is character data. Yet you are now wishing
to put in relative references that have complex semantics
not completely understandable without having the original context of
the document they appear in.


Lots of extensions will be like this. What's one itunes extenstion
without the others? :)


?


In summary, I agree with Mark.


You agree to accept the problems that go with his position, yes.
But why bother when there clearly is an easy solution to the problem  
that works with
the current atom format and which I outlined earlier, namely using  
the link element.

I suggested writing the next tag like this:

http://purl.org/syndication/history/1.0/next"; href="./ 
archives/archive1.atom">


This clearly allows relative uris (if I am not mistaken) without any  
of the problems
we have with the simple extension elements. And it seems to be  
exactly this type of

thing that the link element was designed to do.


Henry Story
http://blogs.sun.com/roller/page/bblfish/


Robert Sayre

Re: Feed History -03

[Robert Sayre]

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 base context to be preserved in a legacy CMS database along
> with each extension, on the off-chance that they might be significant
> seemed to great.

Um, this makes no sense to me. It seems smart to preserve the entry
from which an extension came. If the extension has no base URI itself,
the one from the entry applies, so you can still find it if you think
you need it later.

Robert Sayre

Re: Feed History -03

[David Powell]

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 simple and complex extensions would be used to  
> justify a constraint on the use of context in simple extensions, I  
> would have objected to it.

The constraint on the context is the main reason for the distinction
between Simple and Structured extensions. Why else would we define two
classes of extension if it didn't affect the processing model, and why
else would we make Simple extensions language-insensitive (a very
similar constraint on context, which is spelt out quite clearly, and
therefore presumably not disputed)?

> If you're using something like RDF to model feeds, you already have a
> number of context-related issues to work through, this isn't an extra
> burden.

Yeah a few, Structured extensions are obviously a big one (where the
lang and base context do need to be preserved). 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 base context to be preserved in a legacy CMS database along
with each extension, on the off-chance that they might be significant
seemed to great.

If you think that the context shouldn't be constrained, then maybe
you're right - maybe the constraint was unnecessary; but I think that
the current spec does impose that constraint, albeit too subtly, in
Section 6.4.1 paragraph 2, and that constraint is what I originally
intended.

If a significant number of people have not picked up on this (the lack
of rationale probably didn't help), and would have disputed it, then I
guess that we have a problem.


-- 
Dave

Re: Feed History -03

[Robert Sayre]

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 extensions; if I had known that
> > the division between simple and complex extensions would be used to
> > justify a constraint on the use of context in simple extensions, I
> > would have objected to it.
> 
> The problem is that readers of your xml that wish to store your data
> in some form other than xml (relational database, triple store,
> object oriented database, prolog database,...), and that may
> not at the time of consumption know about your extension will  save
> the content in text, which is all the spec says they should do. Since
> they don't at the time know the meaning of fh:prev and
> in particular that it should contain a URI  they can't save the
> absolute URI it represents.
> All they will be able to save is relative uri which will be
> meaningless if the context of the
> original document is lost.

The app should store the relative URI, and it shouldn't lose the context.

> 
> > If you're using something like RDF to model feeds, you already have
> > a number of context-related issues to work through, this isn't an
> > extra burden.
> 
> The point of making extensions is that they should be interpretable
> or at least in part useable
> by parties that don't understand the extension.

It still is.

> This is a question of the Atom spec saying that the content of a
> simple extension element is character data. Yet you are now wishing
> to put in relative references that have complex semantics
> not completely understandable without having the original context of
> the document they appear in.

Lots of extensions will be like this. What's one itunes extenstion
without the others? :)

In summary, I agree with Mark.

Robert Sayre

I-D ACTION:draft-ietf-atompub-format-11.txt

[Internet-Drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working 
Group of the IETF.

Title   : The Atom Syndication Format
Author(s)   : R. Sayre, M. Nottingham
Filename: draft-ietf-atompub-format-11.txt
Pages   : 56
Date: 2005-8-16

This document specifies Atom, an XML-based Web content and metadata
   syndication format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[EMAIL PROTECTED] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atompub-format-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-ietf-atompub-format-11.txt".

NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: Feed History -03

[Henry Story]

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 extensions; if I had known that  
the division between simple and complex extensions would be used to  
justify a constraint on the use of context in simple extensions, I  
would have objected to it.


The problem is that readers of your xml that wish to store your data  
in some form other than xml (relational database, triple store,  
object oriented database, prolog database,...), and that may
not at the time of consumption know about your extension will  save  
the content in text, which is all the spec says they should do. Since  
they don't at the time know the meaning of fh:prev and
in particular that it should contain a URI  they can't save the  
absolute URI it represents.
All they will be able to save is relative uri which will be  
meaningless if the context of the

original document is lost.

If you're using something like RDF to model feeds, you already have  
a number of context-related issues to work through, this isn't an  
extra burden.


The point of making extensions is that they should be interpretable  
or at least in part useable
by parties that don't understand the extension. RDF has nothing to do  
with this. (Other than
it having some very solid theoretical backing and so being very  
helpful in thinking about these
issues, and also of it having solved quite a few years ago the  
problems that you are just discovering)



I should explicitly allow relative URIs in fh:prev, though.


-1

This is a question of the Atom spec saying that the content of a  
simple extension element is character data. Yet you are now wishing  
to put in relative references that have complex semantics
not completely understandable without having the original context of  
the document they appear in.
I know it may seem to the writer of an extension as if the meaning of  
his extension were clear
as day, but this will not be the case to all consumers of your  
extension, and even if your
extension becomes world famous, it certainly won't be true for all  
the other extensions that people will come up with. So I think we  
should be setting a good example in these first extensions we write.


Henry Story



Cheers,


On 16/08/2005, at 11:35 AM, Henry Story wrote:


I think that in section 5. you should specify that the URI  
reference MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I  
agree with the point made by

David Powell in the thread entitled "More about extensions" [1].

Given that we have this problem I was wondering whether it would  
not be better
to use the link element as I think it permits relative references.  
Relative references
really are *extreemly useful*. I tried to work without them in my  
BlogEd editor
because the Sesame database folk mistakenly thought it was not  
part of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they  
allowed relative references.


So if relative references are allowed in links perhaps the  
following would be better:


http://purl.org/syndication/history/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-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 if fh:prev is  
present
  - clarified that fh doesn't add ordering semantics, just allows  
you to reconstruct state

  - cleaned up text, fixed examples, general standards hygiene

There's going to be at least one more draft, as I neglected to  
acknowledge people who have made suggestions and otherwise helped  
so far. Sorry!


--
Mark Nottingham http://www.mnot.net/











--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Mark Nottingham]

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 which drives  
the document structure. From a client perspective, there are only  
the documents and it derives its own model from that.


Not sure what you mean here; are you saying that fh:archive is  
superfluous?


Currently:
The document first defines "archive documents" and *afterwards*  
requires that fh:archive MUST be present in archive documents.


My proposal:
Introduce fh:archive with the semantics that the server garantuees  
that the set of entries in this document will not change over time  
if fh:archive is present. A document with fh:archive in it (and its  
implied semantics) is then called an "archive document".


To tackle it from another view: The spec should say "servers MUST  
NOT break the promises of fh:archive" instead of saying "archive  
documents MUST announce that they do not change". There is possible  
harm in breaking the first, but only suboptimal performance in  
neglecting the latter case.


I made it loose purposefully; I think there are several types of  
archives out there, and it's likely that further specs are going to  
come along that talk about the guarantees surrounding persistence,  
entry deletion, etc. Again, I want to avoid, as much as possible,  
defining what a feed is in this document, as there are many potential  
models for feeds.


For example, an archive in my blog feed can change for spelling  
mistakes and updates, but an archive of telephone records used for  
SOX compliance can't. Mandating a particular definition of what an  
archive is would necessitate ruling some types of archives out, and  
that wasn't my main use case for this; rather, it was to make sure  
that archive feeds (as defined for the purposes of this spec)  
wouldn't be accidentally subscribed to.


Cheers,

--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Mark Nottingham]

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 simple and complex extensions would be used to  
justify a constraint on the use of context in simple extensions, I  
would have objected to it.


If you're using something like RDF to model feeds, you already have a  
number of context-related issues to work through, this isn't an extra  
burden.


I should explicitly allow relative URIs in fh:prev, though.

Cheers,


On 16/08/2005, at 11:35 AM, Henry Story wrote:

I think that in section 5. you should specify that the URI  
reference MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I  
agree with the point made by

David Powell in the thread entitled "More about extensions" [1].

Given that we have this problem I was wondering whether it would  
not be better
to use the link element as I think it permits relative references.  
Relative references
really are *extreemly useful*. I tried to work without them in my  
BlogEd editor
because the Sesame database folk mistakenly thought it was not part  
of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they  
allowed relative references.


So if relative references are allowed in links perhaps the  
following would be better:


http://purl.org/syndication/history/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-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 if fh:prev is present
  - clarified that fh doesn't add ordering semantics, just allows  
you to reconstruct state

  - cleaned up text, fixed examples, general standards hygiene

There's going to be at least one more draft, as I neglected to  
acknowledge people who have made suggestions and otherwise helped  
so far. Sorry!


--
Mark Nottingham http://www.mnot.net/









--
Mark Nottingham http://www.mnot.net/

Re: xml:base abuse

[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 with normalization and fragment
>> identifiers.  This can only cause confusion if the xml:base in effect
>> differs from original xml:base of the document (i.e., the URI used to
>> retrieve the document in the first place) in ways other than the
>> fragment identifier.
> 
> You've nailed it.

Cool.  Took me long enough.

>> Note that I'm sidestepping all questions about who is right or wrong. 
> 
> I totally agree, there is no right or wrong here. The established usage
> of a base URI is so different from what Roy is saying that he shouldn't
> have changed the RFC in such a way. (The RFC is even an Internet
> Standard, defined as "a specification that is stable and well-understood.")

I'm sure that we can find established usages where the consuming tool
has various degrees of "agressiveness".  Pure speculation on my part,
but now that I have been able to see how limited in scope this issue is,
I can see where spec authors might have had trouble outlawing one
behavior or another, and decided that publishing a spec within a
reasonable timeframe was of greater value than resolving this issue.

>> The recommendations produced by the feed validator will focus on the
>> areas where the user is most likely to stumble into this problem.  It
>> seems to me that the largest problem area is at the feed level, and the
>> recommendation will be to either make xml:base at the feed level match
>> the URI from which the feed was loaded, or (paradoxically enough) to
>> reference a resource 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.
> 
> Yes, although I wonder how you would test for "unlikely to directly
> reference later".

I will only test for actual references that meet the criteria described
at the top of this note.  When I encounter such a condition, I will emit
a warning containing a one line message accompanied by a link.  That
link will take the user to a web page that repeats the one line message,
provides an explation of that message (probably close to what I said at
the top of the page), provide a recommendation (probably close to what I
said in the second paragraph above this one), and a link to the
feedvalidator mailing list.

- Sam Ruby

Re: Feed History -03

[Henry Story]

I think that in section 5. you should specify that the URI reference  
MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I  
agree with the point made by

David Powell in the thread entitled "More about extensions" [1].

Given that we have this problem I was wondering whether it would not  
be better
to use the link element as I think it permits relative references.  
Relative references
really are *extreemly useful*. I tried to work without them in my  
BlogEd editor
because the Sesame database folk mistakenly thought it was not part  
of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they  
allowed relative references.


So if relative references are allowed in links perhaps the following  
would be better:


http://purl.org/syndication/history/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-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 if fh:prev is present
  - clarified that fh doesn't add ordering semantics, just allows  
you to reconstruct state

  - cleaned up text, fixed examples, general standards hygiene

There's going to be at least one more draft, as I neglected to  
acknowledge people who have made suggestions and otherwise helped  
so far. Sorry!


--
Mark Nottingham http://www.mnot.net/

Re: xml:base abuse

[Sjoerd Visscher]

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 with normalization and fragment
identifiers.  This can only cause confusion if the xml:base in effect
differs from original xml:base of the document (i.e., the URI used to
retrieve the document in the first place) in ways other than the
fragment identifier.


You've nailed it.

Note that I'm sidestepping all questions about who is right or wrong. 


I totally agree, there is no right or wrong here. The established usage 
of a base URI is so different from what Roy is saying that he shouldn't 
have changed the RFC in such a way. (The RFC is even an Internet 
Standard, defined as "a specification that is stable and well-understood.")



The recommendations produced by the feed validator will focus on the
areas where the user is most likely to stumble into this problem.  It
seems to me that the largest problem area is at the feed level, and the
recommendation will be to either make xml:base at the feed level match
the URI from which the feed was loaded, or (paradoxically enough) to
reference a resource 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.


Yes, although I wonder how you would test for "unlikely to directly 
reference later".



Fair enough?


Totally, thanks!

--
Sjoerd Visscher
http://w3future.com/weblog/

Re: Feed History -03

[Stefan Eissing]

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't it? You seem to 
have a (server-side) model in mind which drives the document 
structure. From a client perspective, there are only the documents 
and it derives its own model from that.


Not sure what you mean here; are you saying that fh:archive is 
superfluous?


Currently:
The document first defines "archive documents" and *afterwards* 
requires that fh:archive MUST be present in archive documents.


My proposal:
Introduce fh:archive with the semantics that the server garantuees that 
the set of entries in this document will not change over time if 
fh:archive is present. A document with fh:archive in it (and its 
implied semantics) is then called an "archive document".


To tackle it from another view: The spec should say "servers MUST NOT 
break the promises of fh:archive" instead of saying "archive documents 
MUST announce that they do not change". There is possible harm in 
breaking the first, but only suboptimal performance in neglecting the 
latter case.


//Stefan

Re: Feed History -03

[Mark Nottingham]

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 a misalignment here, but would actually resolve  
it the other way. I wanted to encourage fh:archive's presence,  
because it will allow processors to avoid mistakes like subscribing  
to an archive feed. Hence, the SHOULD.


However, fh:stateful would probably be improved by saying it SHOULD  
(instead of MAY) occur in a subscription document's head section, and  
processors MUST (instead of MAY) behave as if it is present and true  
if fh:prev is there.



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 which drives the document  
structure. From a client perspective, there are only the documents  
and it derives its own model from that.


Not sure what you mean here; are you saying that fh:archive is  
superfluous?



--
Mark Nottingham http://www.mnot.net/

Re: xml:base abuse

[Sam Ruby]

Robert Sayre wrote:
> On 8/15/05, Sjoerd Visscher <[EMAIL PROTECTED]> wrote:
> 
>>Yes, it's a known bug.
>>https://bugzilla.mozilla.org/show_bug.cgi?id=275689
> 
> Well, it's not clear from that bug that any Mozilla committers feel
> it's wise to "fix." Even so, they seem to be leaning towards patching
> html:a as a special case, in the event that they do anything.
> 
> I'll agree that this should be a warning, and perhaps write something
> that willcome back to haunt me--Atom makes a point of leaning many
> established specifications. It's unwise to lean on those specs in the
> corner cases where they diverge from existing implementations, and a
> warning in the feedvalidator is justified in such cases.

What I see occurring here is implementations dealing with the attendent
confusions that their users face as the result of an unclear
specification of a corner case in a spec.

After all this discussion, I am *still* unclear as to where this corner
case is.

Let me try again.

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 with normalization and fragment
identifiers.  This can only cause confusion if the xml:base in effect
differs from original xml:base of the document (i.e., the URI used to
retrieve the document in the first place) in ways other than the
fragment identifier.

Sjoerd: is this your understanding?  Note that I'm sidestepping all
questions about who is right or wrong.  Different implementations may
chose different strategies on how aggressive they wish to be.

If my understanding is correct, then I will agree that it is unwise for
feeds to express URIs that some consumers will interpret in one way, and
others will interpret in an other way; therefore a warning is warranted.

If my understanding is correct, I can produce test cases (and would
welcome any contributions in this area), and fix the feed validator.

The recommendations produced by the feed validator will focus on the
areas where the user is most likely to stumble into this problem.  It
seems to me that the largest problem area is at the feed level, and the
recommendation will be to either make xml:base at the feed level match
the URI from which the feed was loaded, or (paradoxically enough) to
reference a resource 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

Re: Feed History -03

[Henry Story]

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 were to take a subscription feed "feed.atom" and map it  
to a graph

you might get something like this:

_feed
  |id--> 
  |---entry> _
  |  |id-> 
  |  |---title---> "first entry"
  |--fh:next---> 


The graph of the history1.atom archive may be:

_feed2
  |id--> 
  |---entry> _
 |id-> 
 |---title---> "another entry"


The role of id is to help us merge the two graphs. IE the point of  
the history
tag is to help us think of the history.atom document as a  
continuation of
the same document, or rather that they are both descriptions of the  
feed with
id . Merging the above two as simple graphs at  
most gives

this


  |--1/id---> _feed
  |   |---entry> _
  |   |  |id-> 
  |   |  |---title---> "first entry"
  |   |--fh:next---> 
  |--1/id--->_feed2
  |---entry> _
  |  |id-> 
  |  |---title---> "another entry"
  |--fh:next---> 


But what we really want is something like this:


  |---entry> _
  |  |id-> 
  |  |---title---> "first entry"
  |---entry> _
 |id-> 
 |---title---> "another entry"


I think we require some form of inferencing beyond what is available  
in OWL
to achieve this result. This could probably be achieved through some  
simple

N3 rules.

Henry Story

Re: xml:base abuse

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2005-08-15 20:15]:
> > That uses html:base, which sets the base URI for the entire
> > document, not @xml:base, which sets the base URI for the
> > element and its children. Your example is irrelevant.
> 
> Oh no, not irrelevance! :)
> 
> Both seem to do the job described in section 5.1.1 of RFC 3986,
> "Base URI embedded in content".
> 

Sorry, I misunderstood what you were trying to demonstrate
because I mixed it up with the discussion about @xml:base
providing a base URI for a subtree of a document only.

In other matters, what Sjoerd said.

Regards,
-- 
Aristotle Pagaltzis // 

Re: xml:base abuse

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2005-08-16 09:40]:
> As long as we're picking on Tim's URI space... what happens in
> this hypothetical situation:
> 
> http://www.tbray.org/ongoing/hubble60.jpg";>
> 
>  alt="stars" 
> src="http://www.tbray.org/ongoing/hubble60.jpg"; />
> 
> 

That’s the same as







ie the document author made a mistake.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Feed History -03

[Stefan Eissing]

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.:   
"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. Proposal:


"The fh:archive element MAY occur in a document's head section  and  
declares that the document is an archive document."


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 which drives the document structure. From  
a client perspective, there are only the documents and it derives its  
own model from that.


Maybe its a matter of taste.

//Stefan