Fwd: Atom format interpretation question

2007-01-04 Thread Tim Bray


Begin forwarded message:


From: John Cowan [EMAIL PROTECTED]
Date: January 4, 2007 8:08:06 AM PST (CA)
To: [EMAIL PROTECTED]
Subject: Atom format interpretation question

Am I right in thinking that content which is in fact in XML but
is labeled with a media type that is neither generic XML nor
ends in +xml cannot be included inline in an Atom entry?
The NewsML community (which uses the registered media-type
text/vnd.IPTC.NewsML) is concerned about this.

--  
John Cowan  [EMAIL PROTECTED]  http://ccil.org/~cowan

Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of  
Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are  
unknown)





Re: AD Evaluation of draft-ietf-atompub-protocol-11

2006-12-16 Thread Tim Bray


On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote:

I guess I'm assuming that one would want clients to be able to  
extend Atom unilaterally.


That doesn't seem to have been a design goal for the WG.  To the  
extent that the issue never came up in the discussion.


The choices that I highlighted as problematic make it harder for  
clients to reliably add extensions to Atom documents.


You're being tactful with harder.  I'd say impossible.

Here's my take on the WG thinking:  The set of software  
implementations which could reasonably act as APP servers is  
incredibly large and heterogeneous.  A lot of them already exist.   
The requirement that they reliably round-trip arbitrary XML from  
clients is actually pretty onerous, since many (all?) of them will  
have internal data-storage models which will look very little like  
the Atom XML representation.


We think that APP as specified allows very good interoperability for  
basic Web-centric publish/edit operations with low overhead, and low  
demands for complexity in the client and sever implementations.
Adding the requirement for client-side extensibility would reduce the  
number of server implementations that would be able to advertise  
conformance with APP, even though they are perfectly capable of the  
highly-useful function possible under APP as of the current draft.


(It remains easy for servers to add extensions to Atom feeds and  
entries using prescribed mechanisms like adding new elements in  
custom namespaces.  )


Right.  Phrased another way, the APP is highly extensible; but the  
current version requires co-operation from both client and server.   
This seems reasonable to me.


It may be that I'm just having trouble accepting that the WG fully  
understands this and has still come to consensus that this is a  
great way to proceed.  Is that the case?


Sort of.  Frankly, there seems to have been very little hunger for  
unilateral client-side extension, and a very strong aversion from the  
server-side people to accepting the round-trip-any-XML requirement.


  -Tim



Re: AD Evaluation of draft-ietf-atompub-protocol-11

2006-12-15 Thread Tim Bray


Lisa Dusseault wrote:

 Can a client modify an entry to contain a link relation element in the
 following cases:

  - To point to a resource on a different server entirely?

 There is no reason to believe that any of these resource are on
 the same machine to begin with. I could POST to media to machine A
 and have the MLE could be created on machine B and the editable media
 resource itself created on machine C.

 This requirement has to be stated explicitly, at least as a SHOULD.

Hmm.  One particular operation in the APP is defined as creating two 
resources; we specify how this is requested and the mechanism by which 
the server communicates the URIs that identify the newly-created 
resources.  It would feel really weird to me to specify anything about 
what servers the resources might be on.  That's not how URIs work or how 
the Web works.  You can't tell by looking at a URI what server the 
resource is on, anyhow.  The URI might not be an HTTP URI. Two URIs that 
look very much the same might reference data on different continents. 
That's the whole point of how URIs work.


Having said that, Lisa has already pointed out shortcomings in the 
number and placement of examples concerning this particular case.  I 
think it'd be a good idea to have the example showing the Media resource 
showing up at http://media.example.com and the MLE showing up at 
http://app.example.com.


But I'd be very much against side-tripping the protocol definition into 
any discussion of servers.


 Can a server ever ignore part of an edit and successfully process 
the rest?



 Yes. Think of a client that throws in a slew of random link elements 
with

 relations my server implementation doesn't understand. Same with foreign
 markup. The server is in charge.

 I completely disagree with this.  It is way too unpredictable for 
clients to deal with.


Well, except there are several examples of APP clients that seem to do 
just fine.


Example: After extensive discussion, the WG achieved consensus that APP 
servers are *not* required to retain foreign markup.


Example: It is perfectly possible to imagine a server that morphs or 
prunes incoming entries for reasons of political censorship, security 
policies, markup standards, spelling-correction, automatic translation, 
or lots of other things we can't possibly imagine.


Example: my Ape protocol exerciser posts entries with a separate 
content and summary fields.  At least one of the servers I've tested 
against accepts posts but discards my summary and generates its own, 
algorithmically.


The range of things a server can usefully choose to do currently exceeds 
our ability to specify or constrain.  Fortunately, in HTTP, we have a 
protocol the semantics of whose state-changing verbs PUT and POST are 
remarkably well-matched for these interactions whereby a client says 
please take this and publish it and tell me what you did and the 
server says OK, here's what I made of it.


The current WG consensus, way better than rough, is that this level of 
interoperation is useful.  That consensus seems to be supported by 
implementation experience.


Lisa, perhaps the problem is that I'm reacting to a fairly general 
statement of concern.  Do you have some specific suggestions as to how 
server behavior could be limited or formally described?


 -Tim



Re: Atom Entry docs

2006-12-14 Thread Tim Bray


Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking 
those existing implementations which follow the existing RFC's.


co-chair-modeIn case you haven't noticed, the WG is hopelessly split 
between the new-media-type option and the media-type-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./co-chair-mode


 -Tim



1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get 
them defined, registered, and ready to use.)

2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml
3) New specifications MAY require that ;type=entry be used. (Note: Just 
because ;type=entry is used DOES NOT imply that ;type=feed must also be 
used)


Thus, APP would accept application/atom+xml when looking for a feed but 
might insist that entries be explicitly identified with a disambiguating 
type parameter. Thus, no code which currently uses 
application/atom+xml to designate a feed would be broken. 
Additionally, any code which is properly built and thus ignores 
unknown types will not be hurt when it sees 
application/atom+xml;type=entry since it will ignore the type 
parameter and dig around inside the data to figure out if it is feed or 
entry. The only code which will be hurt is some potential code that does 
not follow the existing RFCs for Atom or mime types. It is, I think, OK 
to occasionally break code that doesn't follow the specs.


Whatever the technical arguments may be, I believe it is important from 
a political point of view that we do not change the definition of 
things defined in Atom. I am all for extending Atom, but not for 
changing Atom. We must not change the exiting specification unless there 
is some really serious harm being done. If we do, we risk losing the 
trust of at least some members of the community that we've built these 
last few years... Folk will remember that one of the advantages that 
is claimed for RSS is that it has been declared to be eternally free 
from modification. While I personally believe that that is silly, the 
proponents of RSS do have a point when they speak of the value of stable 
specs. If we allow the Atom spec to be *changed* so soon after it was 
accepted and we don't have a really, really good reason for doing it, we 
will simply have proven the often made claim that standards groups 
simply can't be trusted with important specifications. We will be 
encouraging more of the kind of standards making that resulted in the 
mess that is RSS...


bob wyman

PS: Since Kyle points out that GData, a Google product, is potentially 
impacted by the results of this discussion, I should state that I 
currently work for Google -- although I am not currently assigned to any 
product or project that has a direct interest in the definition of Atom, 
APP, etc... My participation in this discussion, at this time, is driven 
purely by personal interest.






Re: Atom namespace really not ending with / or # ?

2006-12-12 Thread Tim Bray


Anne van Kesteren wrote:
Jan Algermissen 
[EMAIL PROTECTED] wrote:
is it really true that the Atom namespace is 
http://www.w3.org/2005/Atom ?


It wasn't really relevant, I'd say. (That it says Atom and not atom 
was a mistake.)


I'd agree.  Sigh.  But not a big one, I think -Tim



Re: Atom Entry Documents

2006-12-12 Thread Tim Bray


Mark Baker wrote:


Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.


Erm, isn't it up to the chairs to declare concensus?


co-chair-modeI agree that there exists sentiment in favor of there 
being a way to distinguish between Feed and Entry documents.  I think 
the notion of consensus is only meaningful in the context of actual spec 
language, so it seems to me that it would be helpful to have some 
proposed language to look at.  So I see no downside in James doing an 
I-D./co-chair-mode


 -Tim



Atom Entry docs

2006-12-12 Thread Tim Bray


I seems obvious to me that Atom Feed and Entry docs are potentially 
quite different things which can be used for entirely different 
purposes.  The contention that an Entry doc is somehow really the same 
as a one-entry Feed doc is entirely unconvincing.


The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG 
finding on Authoritative Metadata 
(http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear 
that it's advantageous to use HTTP headers to distinguish between 
different kinds of representations.


So I guess I'm in favor of us writing something down to address this 
problem.


RFC4287 is now pretty widely implemented, so there is a distinct cost to 
screwing around with the well-known application/atom+xml.  On the other 
hand, my perception is that virtually all software that knows about 4287 
knows about feeds, rather than entries.  Thus, it seems to me that 
introducing a parameter so that existing software might see 
application/atom+xml;type=feed *might* break some software.  But 
introducing a new media-type application/atom-entry+xml which only goes 
with standalone feed documents is very unlikely to break anything.


So I'm for James' option B)
 application/atom-entry+xml

(James, did you really mean atom.entry with the ugly dot?)

 -Tim



Re: PaceEntryMediatype

2006-11-29 Thread Tim Bray


On Nov 29, 2006, at 8:16 AM, James M Snell wrote:


http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...


Irrespective of the merits of the new media type, the APP spec seems  
like the wrong place to define it.  Since nobody wants to obsolete  
4287, why not a short clean standalone I-D?  -Tim




Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

2006-11-28 Thread Tim Bray


On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote:


They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.


Over the course of history, a remarkable number of different groups  
have jumped up and down and said *We're* the ones defining HTML!!!  
Listen to *us*!!!.  It's foolish to draw conclusions about any HTML- 
related spec based either on which group is originating it or what  
anyone claims the browser engineers are going to do.


 -Tim



Re: Author element best practice

2006-11-22 Thread Tim Bray


On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:


Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author


If I were implementing the server, in this scenario I'd reject the  
post with an error message.  It's hard for me to see a scenario where  
the author info isn't already known and not providing it is still  
OK.  (In fact, it's hard for me to imagine a scenario in which the  
author info isn't already known, period.)  -Tim



(which could be considered as not valid but that's not
the question here), now say that my app server does not have any
information as to what value to set when adding the atom:author  
element
to the member, do you think it'd be better to put an empty  
atom:name or

to put a dummy value such as 'anonymous' or 'n/a'?

I'm asking because I try to make sure that whatever the input is the
member I create are respectful of section 4.1.2 of RFC 4287 and I  
can't
decide which way to go when some information are missing from the  
context.


Any best practices from you guys?

Thanks,
- Sylvain





URGENT: Remove atom:updated ordering requirement?

2006-09-27 Thread Tim Bray


co-chair-mode
Please see the dialogue below.
/co-chair-mode

(Eric's point seems plausible to me; personally I'd be inclined to a  
+1.)


co-chair-mode
Can we have some feedback from the WG ASAP?  We want to take  
protocol-11 to the IETF.

/co-chair-mode

  -Tim

On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote:



On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote:


PaceAppEdited: Lots of discussion.  There seems universal support for
the utility of an app:edited element, and an assertion that entry
members SHOULD contain one.  On the other hand, every discussion of
sort order has spiraled instantly into a rat-hole.

Conclusion.  PaceAppEdited is accepted, in part. The second part of
the proposal, defining the app:edited element, is ACCEPTED.  The
first part, imposing a requirement on the sort order of collections,
clearly does not have consensus support.


There also seems to be universal support for the notion that  
collection
feeds could be sorted by something other than what's currently in  
the spec.

The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be  
sorted by

anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

The entries in the returned Atom Feed MUST be ordered by their
   atom:updated property, with the most recently updated entries
coming first in the document order. Clients SHOULD be constructed
in consideration of the fact that changes which do not alter the
atom:updated value of an entry will not affect the position of
the entry in a Collection.

We need to either strike that entire paragraph, or at the very  
least make

that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.







Re: WG Last Call for draft-ietf-atompub-protocol

2006-09-26 Thread Tim Bray


On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote:

Here's a list of Paces that weren't disposed of with the last  
consensus call:


First of all, did Sam get them all?  Please speak up soonest about  
anything that was missed and might have a realistic chance.


co-chair-mode

PaceAppEdited: Lots of discussion.  There seems universal support for  
the utility of an app:edited element, and an assertion that entry  
members SHOULD contain one.  On the other hand, every discussion of  
sort order has spiraled instantly into a rat-hole.


Conclusion.  PaceAppEdited is accepted, in part. The second part of  
the proposal, defining the app:edited element, is ACCEPTED.  The  
first part, imposing a requirement on the sort order of collections,  
clearly does not have consensus support.


 
=


PaceAppEdited2: Not enough support, some opposition, big and  
complicated.  REJECTED.


 
=


PaceAppModified3: Lots of discussion, no real consensus, eventually  
replaced by PaceAppEdited.  REJECTED.


 
=


PaceAppVersion: Got no +1s, some opposition: REJECTED.

 
=


PaceCollectionLinkType: zero discussion: REJECTED.

 
=


PaceFixModel: 2 supporters, not enough: REJECTED.
But note that this is inconsistent with some of the language in  
section 9, so editorial work is required.


 
=


PaceLocationPointsToEntry: zero discussion: REJECTED.

 
=


PaceOrderCollectionsByAppModified2: zero discussion: REJECTED.

 
=


PaceRemoveConnegSuggestionOnServiceDoc: almost no discussion: REJECTED.

 
=


PaceRemoveOutOfLineCategoriesFromCategoryDocument: 2 supporters,  
little discussion, not enough.  REJECTED.


 
=


PaceRevertTitle: Lots of -1's: REJECTED.

 
=


PaceSecurityConsiderationsRevised: We need something in the Security  
Considerations section of the document, and there was at least some  
support for the ideas in this section in the past. The other proposal  
for words for this section was withdrawn. Therefore, this Pace is  
ACCEPTED with the understanding that the issue of what our security  
considerations are is not closed and may be modified after the IETF  
last call.


 
=


PaceServiceLinkType: Not enough discussion/support: REJECTED.

 
=


UseElementsForAppCollectionTitles3: Seems to have been incorporated  
in the draft.


/co-chair-mode






Re: Private extensions and relation to atom elements

2006-09-11 Thread Tim Bray



On Sep 11, 2006, at 4:27 AM, James Aylett wrote:



We've run across a situation where we want to annotate an atom:icon
with a title. Currently we're doing the following, as something that
Feed Validator is happy with, but doesn't feel right:

--
  atom:iconuri:to/icon/atom:icon
  myns:icon-title xml:lang='en' xmlns:myns='...'My icon
title/myns:icon-title


let's assume myns: is declared.  Then why not

icon myns:buddha-nature=high myns:sizzle=lowicon-uriicon

 -Tim



Re: Private extensions and relation to atom elements

2006-09-11 Thread Tim Bray


On Sep 11, 2006, at 7:45 AM, James Aylett wrote:


Feed Validator gets upset with extension attributes - is it wrong?


Be specific, please?  -Tim



Re: atom:updated - not now() values?

2006-08-13 Thread Tim Bray


Eric Scheid wrote:

When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?


Clearly, since updated is defined as the time the publisher thinks it 
was significantly updated.  Of course, the server could over-write the 
updated value if it chose. -Tim




For example: Corporate Communications prep a release and they stamp it with
a release date of Monday 4 PM ... but I don't see this release update until
I get into the office at 2 PM Tuesday, and thus I quickly enter it into the
CMS and set the atom:updated value to Monday 4 PM.

e.





Re: Link rel test cases

2006-05-31 Thread Tim Bray


On May 30, 2006, at 5:25 PM, James Holderness wrote:

I agree completely, but as a content consumer I still need to know  
whether to use IRI::Compare or String::Compare when I do encounter  
some ridiculous feed that uses example (a). I'm hoping for a simple  
answer along the lines of Use IRI:Compare, Use String::Compare,  
or The spec doesn't say, so you may use whatever you prefer.


Both are perfectly legal.  IRI::Compare will avoid some false  
negatives at the cost of burning some CPU cycles.  Postel's law would  
suggest using IRI::Compare initially, but if a profiler revealed it  
to be a performance bottleneck, I'd nuke it in favor of strcmp()  
without a second's hesitation.  I actually wouldn't be surprised if  
that happened; case-insensitivity and Unicode sit poorly together and  
are a notorious source of performance sinkholes. -Tim




Re: Feed Thread in Last Call

2006-05-23 Thread Tim Bray


On May 17, 2006, at 12:46 PM, Byrne Reese wrote:


Speaking up:

http://www.majordojo.com/atom/ 
standardizing_the_atom_thread_extension.ph

p

No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.


Me too.  Does something useful, does no harm, if it's broken in some  
way it'll be harmlessly routed around.  I suspect that  
implementations that are stupid about the contents of atom:link  
will be fixed pretty soon. -Tim




Re: Feed Thread in Last Call

2006-05-23 Thread Tim Bray


On May 18, 2006, at 6:15 AM, David Powell wrote:


What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of RFC4287 there is no problem
with the draft, but practically there is something like a layering
concern if an extension requires existing conformant implementations
to be changed.


At the end of the day, the marketplace will work within the  
constraints of what 4287 allows; my feeling is that there are going  
to be a ton of extensions that will attach unforeseen metadata at  
arbitrary points with Atom documents, and implementations that fail  
to store these and make them retrievable will quickly be seen as  
broken.  -Tim



I notice that you said implemented support - that is fine for
user-agents etc, but I don't believe that Atom infrastructure should
be required to implement support for each new bit of content that
publishers put into their feeds.


On the contrary; I think that implementors who fail to deal with the  
fact that people will be adding their own non-Atom stuff at every  
conceivable place in an Atom feed are being very stupid, because this  
will happen whatever we say. -Tim




Re: Feed Thread in Last Call

2006-05-23 Thread Tim Bray


On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)

I'm going to re-organize David's argument a little and deal with one  
of his last points first.



Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.


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.  After you've noticed that if  
you need nested element structure you're stuck with elements, and if  
you don't want to have two things with the same names attributes can  
help, there really aren't any deterministic decision procedures.


I note with pleasure that *all* known XML APIs allow you to retrieve  
elements and attributes with about the same degree of difficulty.


So, my conclusion: I disagree with Powell.  Let people put extensions  
wherever they feel like putting them (they will anyhow), remembering  
that human-readability is a virtue.  If models try to micro-manage  
the element/attribute thing, those models are broken, don't use  
them.  If software arbitrarily discards markup because the markup  
doesn't match its idiosyncratic ideas about elements and attributes,  
that software is non-comformant and non-interoperable.



Software that deals with XML such as an XHTML document, doesn't have
much choice but to model the document using generic XML concepts and
tools - Infosets, DOM, SAX, strings containing XML tags, etc.

For Atom though, it is useful to model feeds and entries in terms of
some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF,
but that is a dirty word around these parts).


Well yes, but each and every one of those non-XML models fails to  
capture the information content of perfectly-legal XML in one way or  
another.  The Atom data format *could* have been designed in such a  
way as to be conformant with one or more of those models, but it  
wasn't.  Extensions to Atom can be designed in such a way as to fit  
into some particular data model, or not.


So I think it's really questionable to try to normatively reverse  
engineer the WG consensus to try to pretend that Atom documents can  
usefully be processed as anything but XML.



Section 6 of RFC4287 is flawed. It is an ugly mix


I agree.  In fact, what Simple Extension *really* says is this  
property can trivially be modeled in RDF and Structured Extension  
really says is doesn't directly map to RDF, but I failed to  
convince the WG either to remove this hand-waving or to be clear  
about what we really meant.  Having said that, these notions  
fortunately have exactly zero normative effect on implementors.



of my (overly)
strict PaceExtensionConstruct proposal[1], and an (overly) liberal
philosophy that the existence of foreign markup anywhere won't break
implementations, so shouldn't be disallowed.


I have no comment on your proposal, but the philosophy you describe  
does in fact represent the consensus of the WG and the IETF  
community; your opinion that it is overly liberal is interesting but  
not particularly relevant to implementors.



atompub's charter states:


Atom consists of:
* A conceptual model of a resource
* A concrete syntax for this model


Extension elements are defined to have both a model and a syntax, but
Atom's allowance for foreign attributes to appear anywhere is a case
of syntax that has no corresponding model. Atom doesn't really explain
what foreign attributes are intended for.


Extension elements also, as noted above, have *no normative effect*.   
It is arguable that the design of Atom departed from the charter in  
that the model was never explicitly specified.  To me, this seems  
like sound design; the success of the Web has been based on careful  
specification of the content and sequence of the interchanged  
messages without any attempt to standardize on a model.  This is A  
Good Thing, and demonstrably works.


And Atom also doesn't really explain what foreign elements are  
intended for either.



It seems like they could be
an extension point, but given that many implementations will have an
application model that isn't based on the XML Infoset (as described
above),


There's a word for implementations (especially intermediaries, as you  
notice) that aren't based on the Infoset: broken.  Because RFC4287 is  
explicitly defined only in terms of the infoset.  Go ahead and try to  
impose any models that are appropriate for your application needs; I  
do this all the time.  But don't change the Infoset.



it seems very unwise to create an extension proposal which
depends on the precise syntax of an element being preserved.


The precise syntax claim is utterly bogus.  RFC4287 properly  
standardizes at the Infoset level, thus it makes zero difference  
whether I say titleCafé/title or titleCaf#xe9;/title.  I  
personally think that an extension 

Re: Feed thread update

2006-05-04 Thread Tim Bray


On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:


Things would have been far easier if either a) atom:link were
extensible


This assertion that atom:link is not extensible is simply, flatly,  
completely, wrong.  I just went and reviewed 4287 and I think it is  
perfectly clear on this.  I suggest that interested parties review  
sections 4.2.7, 6.3, and 6.4 and, if they still think there is any  
problem with child elements of atom:link, find language in the RFC  
which says something other than what those sections say. -Tim




Re: Feed thread update

2006-05-04 Thread Tim Bray


On May 4, 2006, at 5:25 PM, Kyle Marvin wrote:


the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.


Agreed.  Fortunately the schema's non-normative. -Tim




Re: Feed thread update

2006-05-04 Thread Tim Bray


On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote:


The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.


Mountain, meet molehill.

If it turns out to be useful, it'll stick.  Otherwise not. -Tim



Re: Does xml:base apply to type=html content?

2006-03-31 Thread Tim Bray



On Mar 30, 2006, at 9:20 PM, James M Snell wrote:


I would agree that, as a best practice, the xml:base should appear on
the content element, but implementations need to be prepared to use
whatever the in-scope URI is (e.g. if no xml:base is specified,  
relative

refs in the content will be relative to Content-Location or the feeds
Request URI).


Maybe.  Highly error-prone.


  In other words, consumers of the feed *have* to assume
that the current xml:base in context is going to be correct and
publishers of the feed simply have to be responsible for Doing The  
Right

Thing.


Agreed.  I think providing an xml:base in your feed is a best  
practice. -Tim




Re: atom:name ... text or html?

2006-03-23 Thread Tim Bray



On Mar 23, 2006, at 8:01 AM, Sylvain Hellegouarch wrote:






Seriously though, the atom:name element is described as a human- 
readable name,
Do you mean that human-readable is equivalent to solely English?  
Because as a French, having accents in names is so natural that I  
see it as human readable too ;)


You can have accents, you just can't use HTML entities to get them. -Tim



Re: atom:name ... text or html?

2006-03-23 Thread Tim Bray



On Mar 23, 2006, at 8:57 AM, Eric Scheid 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 actual character  
instead, yes.




It's true that XML has only a half dozen or so entities defined


To be precise, 5: lt; amp; gt; apos; quot; -Tim



Re: atom:name ... text or html?

2006-03-23 Thread Tim Bray


On Mar 23, 2006, at 8:16 AM, Eric Scheid wrote:

If I have an author with the name Bertrand Café, is it acceptable  
to put

that into atom:author like this;

authorname![CDATA[Bertrand Cafeacute;]]/name/author

or should I be using the unicode numeric entity instead?


The key point is that the atom:name element, described in RFC4287  
3.2.1, is not a Text Construct, as defined in 3.1, so you can't say  
atom:name type=html; so no markup allowed.  So just say Bertrand  
Café.  -Tim





Re: atom:name ... text or html?

2006-03-23 Thread Tim Bray



On Mar 23, 2006, at 2:20 PM, Eric Scheid wrote:


Oh well, now to track down a list of html entities and
their corresponding unicodes ...


http://www.google.com/search?q=xhtml%20entities



Re: IE7 Feed Rendering Issue

2006-03-09 Thread Tim Bray


On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote:

I hope this helps make the reasoning behind IE’s behaviour with  
feeds and stylesheets a little less murky.
I don't really have an opinion as to whether this is the ideal  
behavior.  But there is no doubt whatsoever that that Sean's software  
is entirely within its rights.  It is almost never possible nor  
desirable for the transmitter of a general-purpose data format like  
most of those based on XML to try to impose behavior on the  
recipient.  In the big picture, this is one of the big advantages of  
open data formats.


 -Tim




Atom logo where?

2006-03-06 Thread Tim Bray


Where can one go to get versions of the atom logo (the one in view at  
atomenabled.org) in various sizes?  -Tim




Re: Atom logo where?

2006-03-06 Thread Tim Bray



On Mar 6, 2006, at 12:43 PM, Anne van Kesteren wrote:


Quoting Tim Bray [EMAIL PROTECTED]:
Where can one go to get versions of the atom logo (the one in view  
at  atomenabled.org) in various sizes?  -Tim


I guess SVG fits that definition:
http://zcorpan.1go.dk/sandbox/svg/atom/.xml


Oooh, now that is *cool*. -Tim



Re: [rss-public] Microsoft Feeds API Enclosure Test

2006-02-24 Thread Tim Bray


On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote:

I'm sure that many people -- on this list in particular -- think  
that the right thing to do is to normalize to Atom 1.0, instead.  
Yep, that's certainly one way to think about it. But then I'd be  
having this same discussion with Dave and with folks on rss- 
public. :) In short, I'd rather avoid the issue altogether and  
provide some value to the developers who are using the platform --  
which means preventing them from having to learn several different  
formats to get common data, while allowing them to get access to  
extensions.


Given that Atom 1.0, in practice, is a clean superset of RSS 2.0  
(there are things in RSS 2.0 that aren't in Atom, but they are  
typically not used; see http://www.tbray.org/atom/RSS-and-Atom), the  
only one that's been through a formal standardization process, and  
the only that's guaranteed not to change (see IETF rules) this feels  
a little weird.  But it's your API.


I will say, though, that there are already a lot of Atom 1.0 feeds  
and there are going to be more, so it does seem like a basic  
requirement that your interface be able to model Atom 1.0 accurately  
without data loss.  I assume you agree that a failure to do this  
would be a bug. -Tim




Re: Browser behaviour

2006-01-30 Thread Tim Bray



On Jan 30, 2006, at 8:23 AM, James M Snell wrote:



+1. Serving atom up at application/xml is perfectly acceptable


It is *not*.  Atom has a registered Internet media type (application/ 
atom+xml); using anything else is a bug. -Tim




Re: Browser behaviour

2006-01-30 Thread Tim Bray


On Jan 30, 2006, at 12:57 PM, John Panzer wrote:

In other words, the application/xml content is a fallback for when  
users, despite our best efforts, end up looking at XML content  
inside a web browser.  I'd also be happy to make this behaviior  
browser-dependent so that we serve application/atom+xml to browsers  
which will display it inline with a style sheet, if there are any.


This means that users might possibly end up subscribing to  
something of type application/xml if they copy and paste URL #3...  
but we could also make this client dependent so that, for example,  
everything other than known web browsers get application/atom+xml.   
Not sure about that as it's changing the MIME type, but I think  
it's changing it for a good reason (working around what I think is  
a browser problem).


Seems sensible. -Tim



Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]

2006-01-25 Thread Tim Bray



On Jan 25, 2006, at 11:56 AM, James M Snell wrote:



APP should use the values as registered.  That is, previous, next,  
first, last and current.  No need to modify the registrations.


+1



Re: finishing autodiscovery, like now

2006-01-24 Thread Tim Bray



On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:



PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.

Can we please un-expire this:
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

and be done?


+1.  Ship it.  -Tim



--

Robert Sayre

I would have written a shorter letter, but I did not have the time.





Re: Reader 'updated' semantics

2006-01-10 Thread Tim Bray


On Jan 10, 2006, at 9:07 AM, James M Snell wrote:


In RSS there is definite confusion on what constitutes an update. In
Atom it is very clear.  If updated changes, the item has been  
updated.

No controversy at all.


Indeed.  There's a word for behavior of RssBandit and Sage: WRONG.   
Atom provides a 100% unambiguous way to say this is the same entry,  
but it's been changed and the publisher thinks the change is  
significant.  Software that chooses to hide this fact from users is  
broken - arguably dangerous to those who depend on receiving timely  
and accurate information - and should not be used. -Tim




Re: Reader 'updated' semantics

2006-01-09 Thread Tim Bray


On Jan 9, 2006, at 5:08 PM, James M Snell wrote:

The updated element is used to indicate when a significant update  
has occurred to the entry.  If you are updating the updated element  
when you update your entry, you are doing the right thing.  If  
RSSBandit and FeedDemon are not picking up the fact that the entry  
has been modified based on a changed updated value (even if the  
updated element is the only thing that is different), then I would  
say those readers have a bug.  You should never be changing your id  
element value.


James is exactly right.  The whole reason 'updated' exists is  
*exactly* so you can tell the downstream software unambiguously when  
some entry has changed and this ought to be brought to the consumers'  
attention.  -Tim





Re: Tag URIs

2005-12-18 Thread Tim Bray



On Dec 17, 2005, at 9:01 PM, Alan Gutierrez wrote:



I'm to understand that Atom has adopted the Tag URI as a a perferred.
GUID for an Atom 1.0 feed.


It has not.  There is no preferred scheme. -Tim



Re: clarification needed: order of children of atom:entry

2005-10-27 Thread Tim Bray



On Oct 26, 2005, at 9:46 PM, Eric Scheid wrote:



Section 4.1.2 of the Atom Syndication Format spec states this:

   This specification assigns no significance to the order of
appearance of the child elements of atom:entry.

Is this referring to the immediate children only of atom:entry, or  
of all

descendents?


In the XML context, the term child elements is not ambiguous.  So I  
think it means what it says, which is what you want it to mean. -Tim




Re: New Link Relations -- Ready to go?

2005-10-22 Thread Tim Bray


On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote:


How about:

 -  Description: A URI that refers to a feed document containing a  
set of the most recent entries in the feed. This URI is intended to  
be subscribed to to keep abreast of recent changes in the feed;  
when different from the URI of the document where it occurs, it  
indicates that its value should be used for this purpose in place  
of the current document's URI. For example, an archived feed  
document might contain a subscribe relation that points to the  
subscription feed's location, so that clients subscribe to the  
appropriate link. Note that the self relation was designed for a  
similar purpose, but is not suitable for that use in other feeds,  
whereas this relation can be used in those situations.


On consideration, I am -1 to rel=subscribe.  The reason is this:  
one of the big potential value-adds Atom brings is a standards- 
compliant way to do one-click auto-subscribe, via link rel=self / 
.  You are proposing to introduce a link rel=subscribe / which  
is there to support autosubscribe.  But, it turns out, only in the  
special case where the feed is static and you wouldn't actually  
subscribe to it.  I think the risk of confusing implementors and  
weakening the value proposition around link rel=self greatly  
exceeds the benefit of supporting this special case.


Plus, I think the thing isn't properly named.  It isn't actually  
subscribe in the general case, it's in the special case where the  
version you are looking at is static, point to the places where the  
changes happen because they don't happen here.  So, perhaps we  
should consider rel=current-self or rel=dynamic-version or some  
such.


Finally, markup design that claims to enforce a specific action is  
always questionable.  The great virtue of descriptive markup in  
general is that the tags tell you not what to do with things but what  
they are.  So on that basis, rel=current-version or something is  
better design.  -Tim




Re: New Link Relations -- Ready to go?

2005-10-22 Thread Tim Bray


On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote:


I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link  
would
happen to match the 'subscribe' link, which is the exception. The  
defining

text in the spec says this about 'self'

The value self signifies that the IRI in the value of
the href attribute identifies a resource equivalent to
the containing element.

atom:[EMAIL PROTECTED]'self'] can also appear in atom:entry, which would  
be used
for pointing to Atom Entry Documents, which explains why the text  
says the
containing element. I don't believe anyone is thinking we should  
be able to

subscribe to Atom Entry Documents.


I'm entirely unconvinced.  There are two kinds of feed, the dynamic  
kind and the static kind.  For dynamic feeds, use rel=self to  
subscribe.   For static feeds, use some new relationship like  
rel=dynamic to point to the dynamic version that you might  
subscribe to.


I agree that, in retrospect, the spec should have said that one  
intended use of rel=self is to support auto-subscribe.  I don't  
think adding on a new link relationship is the right answer.



Are we yet in a situation were we have a preponderance of deployed  
feeds
using 'self' to mean 'subscribe'? Actually, that's the wrong  
question to ask

(see below)


Well, all the Atom feeds I see use rel=self in the way you'd expect.


Are we yet in a situation were we have preponderance of deployed
applications that look for 'self' for subscription purposes?


Well, no, because we actually don't have that many apps yet that  
really grok Atom.  When they do, and they want to do auto- 
subscription, Atom is well-equipped to support it.


I think we're in the early days of Atom 1.0 adoption, and we can  
very likely
talk up via blogs, articles, etc the idea of subscribe in the  
general case

using @rel='subscribe'.


No.  We already have a way to do that and don't need to invent another.

-1 on rel=subscribe. -Tim

(oh, and I should have said, +1 on the rest of those relationships)



Re: New Link Relations -- Ready to go?

2005-10-22 Thread Tim Bray



On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:

You seem to be saying that because link/@rel=self was designed  
for a specific purpose, and even though its definition is quite  
descriptive (its definition *only* says it should be used to link  
to the current document; -11 says nothing about subscription) it  
should be the only way defined to do subscription.


Agreed that the description could be better.  What I'm actually  
saying is since we already have a way to do subscription, we don't  
need to invent another.  Also that the problem of pointing from the  
static/archived version of a feed to the dynamic/subscribable one is  
a related but different problem, and the one that you ought to be  
solving.



OTOH, I'm happy to make this relation more declarative. How about:

 -  Attribute Value: current
 -  Description: A URI that, when dereferenced, returns a feed  
document containing the most recent entries in the feed.

 -  Expected display characteristics: Undefined.
 -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document).


Thank you.  +1 -Tim



Re: New Link Relations -- Ready to go?

2005-10-21 Thread Tim Bray


On Oct 21, 2005, at 7:38 AM, James Holderness wrote:

The idea being that if you were to come across an archived Atom  
document (however that might happen), the presence of this link  
would, (a) let you know that it was an archive document and thus  
shouldn't be subscribed to, and (b) provide you with a URL with  
which you could subscribe to the actual feed if you so chose.


Makes sense, but not self-evident.  I would think that the usefulness  
of this thing would be improved by a few words of explanation for  
those who come upon it without knowing the history. -Tim




Re: New Link Relations -- Ready to go?

2005-10-21 Thread Tim Bray


On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote:

 -  Description: A URI that refers to a feed document containing a  
set of the most recent entries in the feed. This URI is intended  
to be subscribed to to keep abreast of recent changes in the feed.  
When different from the URI of the document where it occurs, it  
indicates that its value should be used for this purpose in place  
of the current document's URI.


Any suggestions?


Yes.  Acknowledge the specific case of an archival feed, an example  
is worth a thousand words.


And discuss why this exist when Atom already has link rel=self,  
specifically designed to support auto-subscribe. -Tim




Re: Question about [EMAIL PROTECTED]

2005-10-07 Thread Tim Bray



On Oct 7, 2005, at 10:20 AM, Byrne Reese wrote:

Are there any good examples of how the [EMAIL PROTECTED] attribute is  
used?
Over at 'ongoing', I have my own set of categories, so my category  
elements look like


category scheme='http://www.tbray.org/ongoing/What/' term='Business' /

Remember, it's optional, both for the producer and for the consumer  
(Technorati, for example, ignores the scheme); but for well-defined  
taxonomies like Dewey Decimal or whatever, I think it would be a good  
idea to put a URI there to disambiguate them. -Tim




Re: Atom 1.0 ootb with MT3.2

2005-09-09 Thread Tim Bray



On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote:




Here's the feedvalidator results for my journal served up as  
Atom1.0 as

per MT3.2's Atom1.0 template

http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net% 
2Fjournal%2Fatom.xml


I'm getting a 404 on that (or rather the feedValidator is) -Tim




I also see it uses tag: uris as the atom:id value. I think I'll change
the template to use the http: URI generated by MT3.2 for the  
individual

entries instead of the tag: (what the rest of the world calls
permalinks). I haven't tried to import/export to see if the atom:id is
preserved across installations.

Speaking of URIs and IDs, there is a gotcha around archive URIs if you
are upgrading to MT 3.2 [1].

cheers
Bill

[1]
http://www.dehora.net/journal/2005/09/ 
did_you_know_that_mt32_clips_the_basename_to_30_chars_by_default_and_i 
f_youre_not_careful_an_import_will_trash_your_permalinks.html








Re: If you want Fat Pings just use Atom!

2005-08-23 Thread Tim Bray


On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote:


That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature...



No.  See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal
error. -Tim



Yes, exactly what I wrote...


No.  The specification clearly *forbids* proceeding with normal  
processing.  If you get a busted element in a feed, you'd better  
close that connection and open another one. -Tim




Re: If you want Fat Pings just use Atom!

2005-08-23 Thread Tim Bray


On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote:


It's got another advantage.  You connect and ask for the feed.
You get

feed xmlns=http://www.w3.org/2005/Atom;
 ... goes on forever 

and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few bytes after the first
hundred thousand or so entries. -Tim


That’s the first really solid pro-single-doc argument I see…


There's another.  You don't have to create a new XML parser for each  
of the entries.  In most programming environments, that's a time- 
saver. -Tim





Re: If you want Fat Pings just use Atom!

2005-08-23 Thread Tim Bray


On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote:


If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.


That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined. So this scenario is
unconstrained by the XML specifications.


No.  See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal  
error. -Tim




Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

2005-08-22 Thread Tim Bray


On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote:


* Paul Hoffman [EMAIL PROTECTED] [2005-08-21 21:55]:


Ah, I had missed that. This leads to a question for the mailing
list. Does an informative extension that appears at the feed
level (as compared to in entries) indicate:



d) completely unknown unless specified in the extension
definition


Atom itself has precedent for both b) and c). So I would say
it’s d) – but also that aggregators should assume b) when they
don’t know any better.


Right, the only possible answer. -Tim




Re: If you want Fat Pings just use Atom!

2005-08-22 Thread Tim Bray


On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:


Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a  
unique API.


Ahh, I had thought this was a more dedicated ping traffic stream. The
never ending Atom document makes much more sense now.


It's got another advantage.  You connect and ask for the feed.  You get

feed xmlns=http://www.w3.org/2005/Atom;
 ... goes on forever 

and none of the entry documents need to redeclare the Atom namespace,  
which saves quite a few bytes after the first hundred thousand or so  
entries. -Tim




Re: Feed History -03

2005-08-17 Thread Tim Bray


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 to summarise: if you don't want to use the atom:link element  
then perhaps it would
be best to use the xlink:link attributes. I have only read that  
spec quickly [1] but this would

mean that the following

  fh:history xlink:href=./archives.archive1.atom


That would work.  I haven't been following this discussion closely  
enough to understand why there's resistance to atom:link rel=some- 
history-thing ...


 -Tim



Re: xml:base abuse

2005-08-15 Thread Tim Bray


On Aug 15, 2005, at 7:28 AM, Tim Bray wrote:

The way Tim Bray's feed and the examples from James Snell on  
developerWorks use xml:base is what Roy T. Fielding calls an abuse.


I disagree with Roy, but agree that the way my links were set up was  
a little surprising to the eye, so I tweaked.  Check out


http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% 
2Fongoing%2Fongoing.atom


 -Tim




Re: Spec explanations for Pebble?

2005-08-13 Thread Tim Bray


On Aug 13, 2005, at 1:34 AM, Simon Brown wrote:

Just to quote an example, Tim is currently using URL based Atom  
IDs, such as :


idhttp://www.tbray.org/ongoing//id
idhttp://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0/id

If Tim *moves* his blog to www.timbray.com/ongoing, would you  
expect his Atom

IDs to remain the same?


Absolutely, otherwise everyone who subscribes to me is going to see  
all the same old articles again, exactly what atom:id exists to  
prevent.  The fact that I use HTTP URIs for identifiers reflects my  
belief that good Web citizenship requires that once something is  
published and its URI widely disseminated, it should never ever be  
moved; so in my case this scenario is unlikely to arise. -Tim







Re: Spec explanations for Pebble?

2005-08-12 Thread Tim Bray


On Aug 12, 2005, at 1:55 AM, Graham Parks wrote:

categorization scheme means the system used to categorize  
entries. Presumably each blog has its own system for doing so, so  
the scheme attribute should be the same for all posts from the same  
blog, and unique to the blog.


Mostly agree.

Except for, a bunch of blogs might agree to share a categorization  
scheme, so probably not unique to each blog.


But I suspect that the notion of categorization scheme is  
underdefined enough that if someone wanted to use different URIs for  
each page like the example Carey cited, that's really dumb but not  
actually illegal. -Tim




Re: More about Extensions

2005-08-09 Thread Tim Bray


On Aug 9, 2005, at 5:11 PM, David Powell wrote:


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 not expect it to be preserved.


Either the software understands the foreign markup, in which case it  
might recognize a relative URI, in which case it should apply the  
correct base URI, or it doesn't, in which case everything in the  
foreign markup is just a semantics-free string.


The problem could hypothetically arise when someone extracts  
properties from the foreign markup, stuffs them in a tuple store, and  
then when the software that knows what to do with comes along and  
retrieves it and recognizes the relative URI and can't do much  
because the base URI is lost.


So... IF you know how to handle some particular extension, AND IF you  
expect to handle it when the extension data has been ripped out of  
the feed and stored somewhere without any context, THEN you shouldn't  
use a relative reference.  Alternatively, IF you want to empower  
extensions to process they data they understand, AND IF you want to  
rip that data out of the feed and store it somewhere, THEN it would  
be smart to provide software an interface to retrieve context, such  
as feed-level metadata and the base URI.


Sounds like implementor's-guide material to me.

And, to whoever said relative references are fragile: Wrong.  When  
you have to move bales of web content around from one place to  
another, and just supposing hypothetically that you have internal  
links, relative references are robust, absolute URIs are fragile.  -Tim




Re: spec bug: can we fix for draft-11?

2005-08-08 Thread Tim Bray



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 MUST  
be  an

IRI, is clear and simple and supported by other well-understood
normative text, supported by lots of interoperable software, that   
make

the meanings of element, content, and IRI not really open  to
intelligent dispute.  I claim that text enjoyed strong, not rough,
consensus support from the WG.



I believe that the term content is open to intelligent dispute.
Apparently the authors of RFC3470/BCP70 believe so too.


Could you reference that?  It seems to me that the guidance we should  
take from 3470 is from section 4.16, which seems to me to make it  
clear that *we* should make it clear that


id
 http://example.com/foo
/id

is an error and nothing but an error. -Tim



Re: spec bug: can we fix for draft-11?

2005-08-08 Thread Tim Bray


On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote:


To an Infoset person, this following is a completely different stream
from the example above (please ignore any line breaks that your email
client may insert):

atom:id#104;#116;#116;#112;#58;#47;#47;#101;#120;#97;#109 
;#112;#108;#101;#46;#99;#111;#109;#47;#102;#111;#111;/ 
atom:id


I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 6




Infoset views the below two examples as different:

atom:id![CDATA[http://example.com/foo]]/atom:id
atom:idhttp://example.com/foo/atom:id


I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 19


Or am I missing something obvious? -Tim



Re: Comments Draft

2005-08-05 Thread Tim Bray


On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote:


link rel=in-reply-to
  href=http://www.example.com/atom;
  type=application/atom+xml
  thread:idref=urn:foo:1 /

this way processors that have a basic understanding of what a  
link is can

still do something useful.


Uh, consider

link rel=ultimate-source-of-all-evil-STAY-AWAY
  href=http://example.org/evil; /

What useful thing is there that software could sanely do, knowing  
only that something is a link? -Tim





Re: Simple Extensions and xml:base

2005-08-05 Thread Tim Bray


On Aug 5, 2005, at 5:59 AM, David Powell wrote:

We say that Simple Extension Elements are not language sensitive,  
but

They *are* affected by xml:base.  xml:base establishes the base URI
for wherever it's in-scope, with a specific callout to RFC3986 for
the semantics.  Anytime you see something that you know is a relative
URI reference, you have to absolutize it using the base URI, and the
base URI is what xml:base says it is.  -Tim


Yes, I understand, but I disagree.  xml:base only affects things  
that are

designated to be URI references.  I wouldn't expect
atom:title/index.html/atom:title to get resolved as a URI, because
atom:title isn't defined to be a URIRef.  Neither are Simple Extension
Elements.


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




Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Tim Bray



On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote:



At 7:37 PM -0400 8/2/05, Robert Sayre wrote:


One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _.



That works for me. Another idea is Atom Processors MAY ignore  
leading and/or trailing whitespace in elements whose content does  
not allow leading and/or trailing whitespace, such as IRIs and  
.


The more I think about this family of suggestions, the less I like  
them.  There is no coherent argument from the published  
specifications of XML and IRIs that allows our 4.2.6 language Its  
content MUST be an IRI to regard


atom:id
http://example.com/foo
/atom:id

as anything but an error.  I suggest an alternate formulation:
===

Implementors are advised that there is a common class of error in  
which, when the content of an element is specified as being an IRI,  
software which generates Atom documents introduces spurious white  
space before and after the IRI, for example:


atom:id
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
/atom:id

In this case, since [RFC3987] makes it clear that the leading and  
trailing white space cannot be part of the IRI, implementors MAY  
choose to be forgiving in regards to this error, by ignoring the  
leading and trailing white space.

===

I'm strongly -1 on treating this as anything but an error.  We may at  
our discretion make it forgiveable.  This formulation would also  
allow the feed validator to complain.


I suppose if we did this, we should generalize it slightly to apply  
to date constructs as well. -Tim





Re: spec bug: can we fix for draft-11?

2005-08-04 Thread Tim Bray


On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote:


I propose trying harder, but I am open to just fail.


As am I. I am not OK with a long treatise on whitespace, like the one
Tim suggested. If there is a MUST-breaking error in a feed, that's not
an Atom document and I don't want to talk about  it. I slightly prefer
documenting and allowing what the world's PHP scripts have been
observed to produce, but either way is fine. BTW, my proposed text was
taken from HTML 4.01.


I'm getting increasingly grumpy and just fail is looking better and  
better.  The current normative text, The element's content MUST be  
an IRI, is clear and simple and supported by other well-understood  
normative text, supported by lots of interoperable software, that  
make the meanings of element, content, and IRI not really open  
to intelligent dispute.  I claim that text enjoyed strong, not rough,  
consensus support from the WG.


So my preferred course of action would be to leave it the way it  
bloody well is.  The Feed validator should throw whitespace-polluted  
pseudo-Atom on the floor, and if some bozos persist in producing it,  
and some implementors decide to work around this error, well, that's  
the way the Internet is.  But if a couple of leading implementations  
decide to be strict, and the producers develop a culture of Doing The  
Right Thing, well then, that's the way the Internet is too,  
sometimes.  PHP is, if nothing else, flexible and friendly to quick  
changes in deployed scripts, I can hear a zillion publishing-system  
hackers grumbling Oh, it's that damn tight-assed Atom stuff, guess I  
have to use mod_finicky here.


So for now, I'm -1 on an weakening or removing The element's content  
MUST be an IRI or analogous text in any other section. I'll stop  
shouting if I'm in a small minority here.  -Tim





Re: spec bug: can we fix for draft-11?

2005-08-02 Thread Tim Bray


On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote:


One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _. That is, no existing
software is buggy, but if you want to be sure your document is
processed accurately, you should trim the space yourself.


Ecch.  Blecch.  Barf.

I suppose.

I personally think the framework of specifications is crystal-clear,  
and per the letter of the law


atom:id
http://example.com/foo
/atom:id

is totally illegal because the string \nhttp://example.com/foo\n does  
not conform to the productions for either URI or IRI.


I am less convinced that people are actually going to do this, but I  
do agree that if a substantial number *do* do this, implementors will  
simply ignore us and code around it.  So if the WG really thinks this  
is a sensible clarification I won't scream too much.  -Tim




Atom 1.0 xml:base/URI funnies

2005-07-16 Thread Tim Bray


I got an email last night from a well known syndication implementor  
pointing out an obvious bug in my Atom feed.  The feed's valid, but  
the stuff in content was full of relative URIs which were broken  
because I'd borked the xml:base.  So I went through the code and got  
the xml:base right and ruthlessly pruned all the pointers.  The feed  
looks a little weird and it's giving the (pre-alpha) validator a  
heartburn, but I sort of think it's right.  I also think it's good  
practice.  Check it out:


feed xmlns='http://www.w3.org/2005/Atom'
  xml:base='http://www.tbray.org/ongoing/'
  xml:lang='en-us'
titleongoing/title
link href='' /
link rel='self' href='ongoing.atom' /
logorsslogo.jpg/logo
icon/favicon.ico/icon
updated2005-07-16T11:17:23-08:00/updated
authornameTim Bray/name/author
subtitleongoing fragmented essay by Tim Bray/subtitle
idhttp://www.tbray.org/ongoing//id
rightsAll content written by Tim Bray and photos by Tim Bray  
Copyright Tim Bray, some rights reserved, see /ongoing/misc/ 
Copyright/rights
generator uri='misc/Colophon'Generated from XML source code using  
Perl, Expat, XML::Parser, Emacs, Mysql, and ImageMagick.  Industrial  
strength technology, baby./generator

entry xml:base='http://www.tbray.org/ongoing/When/200x/2005/07/14/'
  titleAtom 1.0/title
  link href='Atom-1.0' /
  idhttp://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0/id
  published2005-07-14T13:00:00-08:00/published
  updated2005-07-16T11:17:12-08:00/updated
  category scheme='http://www.tbray.org/ongoing/What/'  
term='Technology/Atom' /
summary type='xhtml'div xmlns='http://www.w3.org/1999/xhtml'It’s  
cooked

  ... eliding ...
content type='xhtml'div xmlns='http://www.w3.org/1999/xhtml'
  ... eliding ...
  img class=inline src=Atom.png alt=Atom/




Re: Atom 1.0 xml:base/URI funnies

2005-07-16 Thread Tim Bray


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.

While it clearly shouldn't be the default behavior, longer term  
(i.e., sometime well after basic Atom 1.0 support is more  
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?


I was actually going to propose that very thing.  I think it would be  
highly useful.  -Tim





Re: Atom 1.0 xml:base/URI funnies

2005-07-16 Thread Tim Bray


On Jul 16, 2005, at 11:20 AM, Tim Bray wrote:

I got an email last night from a well known syndication implementor  
pointing out an obvious bug in my Atom feed.  The feed's valid, but  
the stuff in content was full of relative URIs which were broken  
because I'd borked the xml:base.  So I went through the code and  
got the xml:base right and ruthlessly pruned all the pointers.


Hey hey hey, it turns out xml:base is supposed to stack.  Thus.

feed xmlns='http://www.w3.org/2005/Atom'
  xml:base='http://www.tbray.org/ongoing/'
  xml:lang='en-us'
titleongoing/title
link href='' /
link rel='self' href='ongoing.atom' /
  ...
entry xml:base='When/200x/2005/07/14/'
  titleAtom 1.0/title
  link href='Atom-1.0' /





The Atomic age

2005-07-15 Thread Tim Bray


Paul assures me that the remaining IETF process steps will not  
introduce material technical changes, and so format-10 is appropriate  
as a basis for implementors to go to work.  So, implementors... to  
work.  And everyone, now is a good time to tell the world.  -Tim




Re: The Atomic age

2005-07-15 Thread Tim Bray



On Jul 15, 2005, at 8:56 AM, Walter Underwood wrote:



--On July 14, 2005 11:37:05 PM -0700 Tim Bray  
[EMAIL PROTECTED] wrote:




So, implementors... to  work.



Do we have a list of who is implementing it? That could be used in
the Deployment section of http://www.tbray.org/atom/RSS-and-Atom.


Good idea.



Ultraseek will implement Atom. We need to think more about exactly
what it means for a search engine to implement it, but we'll at
least spider it.


Want to write a few words in web-space somewhere, Walter, and we can  
put that in the Wiki? -Tim




Re: The Atomic age

2005-07-15 Thread Tim Bray



On Jul 15, 2005, at 12:35 PM, Robert Sayre wrote:



http://feedvalidator.org/check.cgi?url=http%3A%2F% 
2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F


Hmm... the feed looks OK to me; I wouldn't be surprised if it's  
tickling a bug in the just-barely-into-beta Atom 1.0 feedvalidator  
code. -Tim





:)

Robert Sayre

On 7/15/05, Graham [EMAIL PROTECTED] wrote:



On 15 Jul 2005, at 4:56 pm, Walter Underwood wrote:



Do we have a list of who is implementing it? That could be used in
the Deployment section of http://www.tbray.org/atom/RSS-and- 
Atom.




My blog has one here:
http://www.fondantfancies.com/blog/atom1/

I think it's valid, though it's hard to tell without a validator or
even a parser. I'm currently rewriting the engine of Shrook to be
compatible too.

(You may also notice I'm doing my little bit to make sure atom:id is
implemented properly)

Graham Parks










Atom format progress

2005-07-07 Thread Tim Bray


co-chair-mode
The Atom Format draft was considered by the IESG today, and there  
remain some outstanding DISCUSS issues, see:


https://datatracker.ietf.org/public/pidtracker.cgi? 
command=print_ballotballot_id=1681filename=draft-ietf-atompub-format
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_iddTag=11964rfc_flag=0


We need a format-10 draft to incorporate solutions to these; Rob and  
Mark are on it.  The WG has seen all the currently-planned changes,  
so -10 should have no surprises.  Paul is working (a huge amount,  
you'd be astounded) on interfacing to the IESG.


Stand by. -Tim
/co-chair-mode



Re: Major backtracking on canonicalization

2005-07-06 Thread Tim Bray



On Jul 6, 2005, at 3:28 PM, Paul Hoffman wrote:



Greetings again. I gravely misunderstood XML Canonicalization, and  
as it has been explained to me now, XML Canonicalization would be a  
disaster for Atom: what we want is Exclusive XML Canonicalization.


Urgh, I should have caught this.  Correct.  +1 -Tim



Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread Tim Bray


On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:


We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break  
and
discard signatures in order to perform usual and customary  
processing on
entries that falls very close to the realm of interoperability if  
not within
it. Deferring this issue until the implementer's guide is written  
is likely
to defer it beyond the point at which common practice is  
established. The
result is likely to be that intermediaries and aggregators end up  
discarding

most signatures that appear in source feeds.


Huh?!  Pardon my ignorance, could you please provide an explanation  
for the simple-minded as to how the absence of a source element in a  
signed entry will lead to signatures being discarded?  Also, it would  
be helpful to sketch in some of the surrounding scenario... -Tim




Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread Tim Bray


On Jul 5, 2005, at 9:27 AM, James M Snell wrote:
Huh?!  Pardon my ignorance, could you please provide an  
explanation  for the simple-minded as to how the absence of a  
source element in a  signed entry will lead to signatures being  
discarded?  Also, it would  be helpful to sketch in some of the  
surrounding scenario... -Tim


Bob can clarify exactly what he means but from my perspective it  
comes down to an aggregation problem.  If a signature is generated  
over an entry that does not contain an author element or a source  
element, that entry cannot be re-enveloped into an aggregate feed  
that does not contain a top level author element without breaking  
the signature


Well, yes.  Anyone who understands digsig, even someone such as  
myself with only a surface knowledge, can see this.  You can't change  
a signed object without breaking the sig, that's the point.  If I  
want to sign an entry and also want to make it available for  
aggregation then yes, I'd better put in an atom:source.  But this is  
inherent in the basic definition of digsig; not something we need to  
call out.   -Tim




Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread Tim Bray


On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote:


I'm fine with the delay. Two or three weeks on top of 18 months is
not a big deal.


I am *not*.   It's not two or three weeks, it's some  
uncontrollable time in the future versus now.  We have spent way  
too long already. -Tim




Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread Tim Bray


On Jul 5, 2005, at 1:05 PM, David Powell wrote:


Will we still be fixing some of bugs raised since the last draft
though?


Definitely.  A number of things have been pointed out as bugs,  
there's been no WG pushback on any of them, and since we were going  
to have to have a -10 draft anyhow for the namespace, we will roll in  
those fixes, as well as resolving any IESG-raised issues.  -Tim




Specifically, what are the resolutions for the disputed ban on
composite MIME types [1], and some of the specific bugs in section 6
[2] (mismatches with the RelaxNG etc)?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15911.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html

--
Dave






Re: Roll-up of proposed changes to atompub-format section 5

2005-07-05 Thread Tim Bray



On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote:

Intermediaries such as aggregators may need to add an atom:source  
element to an entry that does not contain its own atom:source  
element. If such an entry was signed, the addition will break the  
signature. Thus, a publisher of individually-signed entries should  
strongly consider adding an atom:source element to those entries  
before signing them.


Grumble grumble OK.  -Tim



Re: Roll-up of proposed changes to atompub-format section 5

2005-07-04 Thread Tim Bray



On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote:



   I believe it would be very useful to specify that signed entries  
should include a  source element. This can/should be considered  
part of entry canonicalization.


-1.  Leave it to the market.  I suspect that you're right, but I'd be  
unsurprised if an application for signed un-sourced applications  
turned up.  -Tim


   The reason I suggest this is that signed entries are only really  
useful when extracted from their original source feeds. If entries  
are only read from their source feeds, then it is probably best for  
publishers to sign the feed, not the individual entries. (Note: It  
is my hope that feed publishers will anticipate that their entries  
will be extracted from the source feeds and will thus sign the  
individual entries rather than the feeds... i.e. Publishers should  
anticipate that intermediaries like PubSub and various other search/ 
discovery services will aggregate their entries and republish them  
in non-source feeds.)
   When an entry is removed from its source, it SHOULD have a  
source element inserted if one is not already present. However, if  
a republisher inserts a source element into a signed entry that  
would break the signature. Thus, it seems reasonable that we should  
strongly encourage those who sign entries to anticipate the needs  
of subsequent processors by inserting the source elements in the  
original signed entries. By inserting the source elements, the  
requirement for others to break the signature will be drastically  
reduced. If an entry is signed, yet contains no source element,  
much of the utility of the signature (allowing verification of the  
original publisher) is eliminated.


   bob wyman







Re: Clearing a discuss vote on the Atom format

2005-07-01 Thread Tim Bray



On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote:



Greetings again. Russ Housley, one of the two Security Area  
Directors, has placed a discuss vote on the Atom format document.  
You can read it at https://datatracker.ietf.org/public/ 
pidtracker.cgi?command=view_commentid=36890. Fortunately, it  
seems reasonably easy to clear this discuss.


I'm +1 on Paul's changes. One editorial comment:


To be added near the beginning of Section 5 of atompub-format:

   Producers of feeds and/or entries, and intermediaries who aggregate
   feeds and/or entries, may have sound business reasons for signing
   and/or encrypting otherwise-unprotected content. For example,
   a merchant might digitally sign a message that contains a discount
   coupon for its products. A bank that uses Atom to deliver customer
   statements is very likely to want to sign and encrypt those
   messages to protect their customers' financial information and to
   assure the customer of their authenticity. Intermediaries may want
   to encrypt aggregated feeds so that a passive observer cannot tell
   what topics the recipient is interested in. There are hundreds
   of other reasons why Atom documents might be signed, encrypted,
   or both.


I'd cut this back to one sentence saying.

There are many application scenarios where Atom users will wish to  
apply digital signature, encryption, or both to Atom documents.


The examples are non-comprehensive now and will probably look  
hopelessly quaint before too long.


But if people prefer Paul's language I can live with it. -Tim



Re: IESG defers discussion of the format document for two weeks

2005-06-23 Thread Tim Bray



On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote:


In other words, this isn't bad news, just a delay.


Fully disagree.  The world has many implementors eagerly awaiting the  
arrival of Atom so they can start using it.  If there are problems  
that require repair, I don't want to wait two more weeks to find out  
about them.  This is very disappointing. -Tim




Re: IESG defers discussion of the format document for two weeks

2005-06-23 Thread Tim Bray



On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:


If there are problems
that require repair, I don't want to wait two more weeks to find out
about them.  This is very disappointing. -Tim




we can start with these two...

https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_commentid=

36536

https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_commentid=

36539


Nope, these are non-controversial editorial improvements which need  
not slow us down, they can go into that last draft that we'd have to  
do anyhow to fix the errors that have been turned up and put in the  
contributors and so on.  Specifically, they want us to make it  
clearer that yes, we do have two similar-looking instances of type=  
with different rules, and to make it clear that to dereference a IRI  
you have to turn it into a URI.  The person who put the defer on  
didn't raise these issues.  -Tim





Re: Signature wording

2005-06-22 Thread Tim Bray


On Jun 22, 2005, at 11:55 AM, James M Snell wrote:



Note that I am not trying to change Atom's model or the core spec,


We do agree on Paul's suggested changed saying it's OK to sign  
entries though, I think.


I am trying to define an Atom extension that is capable of meeting  
a specific problem space that happens to include the types of  
things aggregators are going to want to be able to do.


I think this is a good idea.  I'd be pretty strongly against us  
trying to write some sort of c14n language into the format spec  
because we have little prior art to draw on with respect to XML  
DigSig in general, and exactly zero (as far as I know) to draw on for  
digsig in a feed or aggregated-feed context.  So we just totally  
don't know how this is going to shake down in the market.


So I agree.  Remove the prohibition on signing entries, and let the  
engineers figure out what works. -Tim




Re: Signature wording

2005-06-22 Thread Tim Bray


On Jun 22, 2005, at 12:03 PM, James M Snell wrote:

I'm planning to write a separate Internet-Draft that discusses  
digital signing of Atom feeds and entries.  Some parts of that  
document will includes mandates; other parts will include  
recommendations.  We can describe for entry producers a way of  
producing signed entries that can be aggregated with original  
signatures in tact and a set of recommendations to aggregators that  
wish to pass those signed entries around with signatures in tact.   
Sure, it's all up to the aggregators and content providers to  
decide whether or not they want to support those methods -- which  
is the whole point of I'm working on this as a separate I-D and  
positioning it as an optional extension to Atom. :-)


A man who spots a problem, then volunteers to do the work around  
fixing it!  We need more like that.  I suspect that there's an  
excellent chance that this might become a WG draft, but I remained  
concerned about our lack of hands-on experience. -Tim




Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-18 Thread Tim Bray



On Jun 18, 2005, at 8:00 AM, David Powell wrote:



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.


co-chair-modeI disagree.  Atom 0.3 had explicit built-in support  
for multipart, and there was strong (not rough) consensus support for  
retiring that and replacing it with the language in the current draft.


My recollection of the debate is that it was exclusively focused on  
the problems of multipart in the document, thus I proposed to the WG  
that we did not in fact have consensus of banning it in external  
content; the feedback so far is supportive of the notion that that's  
a bug in the spec.

/co-chair-mode



Re: question about future

2005-06-18 Thread Tim Bray



On Jun 18, 2005, at 1:15 PM, Domel wrote:



How many drafts will you planing to publish to Atom 1.0?


That depends on what the IESG says at their meeting of June 23rd.  If  
they say OK there will be a last draft to fix some typos and bugs  
that people have turned up in -09 and include the final namespace and  
so on.  If they request changes it gets more complicated. -Tim











Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists

2005-06-17 Thread Tim Bray


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 4.1.3.1


Failing that, it MUST be a MIME media type.  If the src attribute  
is not provided, i.e. the content is local, the value of the type  
attribute MUST NOT be a composite type... 


-Tim

On Jun 17, 2005, at 7:05 AM, Mark Baker wrote:


atom:content type=message/rfc822
src=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, the value of the type attribute  
MAY be

  one of text, html, or xhtml.  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of text.

where composite type is defined to be multipart/* and message/*.  If
the intent of that restriction was to avoid the whole non-XML
attachments issue, then it seems to have failed to account for the use
of the src attribute to include the data by reference rather than by
value.






Re: Review of Section 6

2005-06-09 Thread Tim Bray


On Jun 9, 2005, at 9:22 AM, David Powell wrote:

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:


I've asked Paul, and in fact we can fix typos and outright bugs later  
on in the process.  If you're right about the Relax mismatch (Rob?   
Norm?) then let's fix that.


On the other hand, a general re-organization of section 6 is right  
out; it is our finding that the format-09 draft (modulo errors)  
reflects the rough consensus of the WG.  If you disagree, the IETF  
provides appeal procedures.


a) Section 6.4 omits atom:source as a valid location for Metadata  
Extensions,
but it is allowed by the RelaxNG in 4.2.11.  I believe that the  
RelaxNG
reflects our intent to allow extensions to be preserved in  
atom:source.


Sounds right to me.

b) Section 6.4.1 and Section 6.4.2 don't 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 should be  
reserved for

future forwards-compatable revisions of Atom.


I find this surprising too, will check further.  -Tim



Re: Moving along with protocol work

2005-06-02 Thread Tim Bray


On Jun 2, 2005, at 10:37 AM, Greg Smith wrote:


Can you point to a link describing maybe the process
and specifically the structure, format, and submission
guidelines for official documents such as a Pace.


Don't know of such a link, so here's how it works.

Well, go to the wiki (starting at http://www.intertwingly.net/wiki/ 
pie/AtomPubIssuesList) and read a few Paces to get a feel for it.   
What I usually do is find a Pace that's suggesting changes similar in  
flavor to the ones I have in mind, hit Edit this page, copy, the  
source code, hit cancel, then if I want to create  
PaceTimsBrainstorm  I go and edit http://www.intertwingly.net/wiki/ 
pie/TimsBrainstorm, the Wiki notices that it doesn't exist, I hit  
create this page and paste in all the source I copied from the  
previous page, edit it, and there you go.


Exception: if it's a big complicated hairy thing, I take the saved  
source and paste it into my desktop text editor and fix it up there  
before I paste it into the new page.


If you know some other people on the list who you think might agree  
with you, contact them have them take a look at the Pace and suggest  
improvements.


Once you've done that, send a message to the list saying I just  
posted PaceXXX.  Some people actually copy the text of the Pace into  
the email, others just post a link,.


Then duck.

-Tim



OpenSearch RSS

2005-05-30 Thread Tim Bray


Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
to hear substantial buzz around this thing.


I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
cause any heartburn?  I'm inclined to think not, but would appreciate  
others having a look.


I get the feeling that OpenSearch + Atom could be real useful. -Tim



Re: some xmlns:atom tomfoolery

2005-05-28 Thread Tim Bray


On May 28, 2005, at 2:09 PM, John Panzer wrote:


   entry
   titlethe minimal Atom Entry/title
   summaryA minimal entry has only .../summary
   content type=application/atom+xml
   entry
   ...
   /entry



Or perhaps:
   feed
  ...
   /feed


You guys are sick, evil, and twisted.  Snicker.   -Tim



Re: [Fwd: Re: Signatures - I blog, therefore I am...]

2005-05-27 Thread Tim Bray


On May 27, 2005, at 11:23 AM, James M Snell wrote:

In general, the idea of associating the signing keys with the  
network resource (feed or entry document URI) makes a lot of sense  
but I think there may be some issues there with aggregate feeds and  
intermediaries (e.g. Feedburner) that would need to be worked out.  
In any case, this is definitely something that should be worked up.  
If there is interest in coming up with a ID on the topic, I  
volunteer to help write it up. The question is whether or not this  
list is the right place to discuss extensions like this or whether  
we should take this offline?


I think that this list is the perfect place to discuss this stuff,  
the people who care are here.


Also, until we get AtomPubIssuesList cleaned up and the format I-D  
filed, the WG is kind of between tasks, so now is a good time.   -Tim




Last and final consensus pronouncement

2005-05-26 Thread Tim Bray


co-chair-mode
On behalf of Paul and myself:  This is it.  The initial phase of the  
WG's work in designing the Atompub data format specification is  
finished over, pining for the fjords, etc.  Please everyone reach  
around and pat yourselves on the back, I think the community will  
generally view this as a fine piece of work.


Stand by for announcements on buckling down on Atom-Protocol.

Note that this is a pronouncement, not a call for further debate.   
Here are the next steps:


1. Editors take the assembled changes and produce a format-09 I-D.   
Sooner is better.

2. They post the I-D.
3. Paul sends Scott a message, cc'ing the WG, that we're done.
4. At this point there may be objections from the WG.  We decide  
whether to accept the objections and pull the draft back, or tell the  
objectors they'll have to pursue the appeal process.
5. The IESG process takes over at this point and we'll eventually  
hear back from them.


Last two draft changes:

1. PaceAtomIdDOS

We think that the WG has consensus that it is of benefit to add a  
warning to section 8 Security Considerations.  The language from  
PaceAtomIdDos is mostly OK, except that the late suggestion of  
talking about spoofing instead of DOS seemed to get general support.   
I reworded slightly.  We'll leave it up to the editors to decide  
whether a new subsection of section 8 is required.


Atom Processors should be aware of the potential for spoofing  
attacks where the attacker publishes an atom:entry with the atom:id  
value of an entry from another feed, perhaps with a falsified  
atom:source element duplicating the atom:id of the other feed. Atom  
Processors which, for example, suppress display of duplicate entries  
by displaying only one entry with a particular atom:id value, perhaps  
by selecting the one with the latest atom:updated value, might also  
take steps to determine whether the entries originated from the same  
publisher before considering them to be duplicates.


2. PaceAtom10

http://www.intertwingly.net/wiki/pie/PaceAtom10

We just missed this one in the previous consensus call; seeing lots  
of +1's and no pushback, it's accepted.

/co-chair-mode




Editorship announcement

2005-05-26 Thread Tim Bray


co-chair-mode
As we get ready to buckle down on the Atom Publishing Protocol draft,  
we're doing some editor-shuffling.  With thanks to Rob Sayre for his  
excellent work up through protocol-04, we're shifting from Rob-and- 
Joe to Joe Gregorio and Bill de hÓra as co-editors of the Atom  
protocol draft.


 -Tim (on behalf of myself and Paul)
/co-chair-mode



Consensus snapshot, 2005/05/25

2005-05-25 Thread Tim Bray


The level of traffic in recent days have been ferocious, and reading  
through it, we observe the WG has consensus on changing the format  
draft in a surprisingly small number of areas.  Here they are:


1. The restriction that atom:author can appear only once is removed.

2. The draft should include an explanation that if entry/author is  
absent, then all entry/source/author entries apply if there are any,  
otherwise all feed/author entries apply.


3. Change to previous consensus call.  The phrase that begins If  
multiple atom:entry elements with the same atom:id value appear in an  
Atom Feed document, they describe the same empty... loses the  
language about how software MUST treat them as such.


4. atom:id is a compulsory child of atom:feed (or did we already say  
that?)


5. rework the last paragraph of 4.1.3.2.  First of all, the  
description involving text/ and +xml needs fixing per Thomas  
Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/ 
msg15444.html), and second, the SHOULD is gone, see http:// 
www.imc.org/atom-syntax/mail-archive/msg15412.html


Have I missed any?  Yes, there has been high-volume debate on several  
other issues; but have there been any other outcomes where we can  
reasonably claim consensus exists?  -Tim




Re: extension elements inside link elements?

2005-05-25 Thread Tim Bray


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.  The point  
is, either software knows what to do with an extension and does it,  
or if not it's not allowed to to break and should pass text through  
in contentful contexts. -Tim





* We have content constructs which are extensible by allowing any type
of data to be embedded using the IANA registry of MIME types.

* We have carefully designed an IANA registry for @rel values, and  
used

the distributed nature of namespace URIs to allow for unregistered
values.

* We have carefully defined two classes of extension construct (Simple
and Structured) to ensure that extensions are disambiguated by
namespace URIs, and that xml:lang issues are considered. Simple
extensions make generic support for this class of extension feasible
for real-world implementations; Structured extensions are there for
those that need the extra power.

And, we have unknown foreign markup.


I believed that the purpose of unknown foreign markup was to define
an error handling strategy for parsers, and to give the spec a bit of
breathing room for things like Atom 1.1.  This is great.

But I'm getting a sneaking suspicion though, that unknown foreign
markup is positioning itself as a third (poorly thought through)
class of extension point.

Please tell me that that isn't the intent?



In the future someone said:


Hey, I've had an idea for an extension to atom:link.  The text  
content
of atom:link could be a tooltip giving a long description for the  
link

It would work like this:

atom:link rel=alternate href=http://example.com/dave;
  This is a picture of my holiday.  I'm the one on the right.
/atom:link

What do you think?




In the future someone said:


Hey, I've had an idea for an extension to atom:link.  The text  
content

of atom:link could be a GUID of an ActiveX control that is capable of
displaying the linked object.  It would work like this:

atom:link rel=alternate href=http://example.com/dave;
  0A28AB31-3143-4b70-B969-8650BDFDBAC9
/atom:link

What do you think?




--
Dave






Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)

2005-05-25 Thread Tim Bray



On May 25, 2005, at 1:49 PM, Graham wrote:


Atom Processors should be aware of the potential for denial of  
service attacks where the attacker publishes an atom:entry with  
the atom:id value of an entry from another feed, and perhaps with  
a falsified atom:source element duplicating the atom:id of the  
other feed. Atom Processors which, for example, suppress display  
of duplicate entries by displaying only one entry with a  
particular atom:id value or combination of atom:id and  
atom:updated values, might also take steps to determine whether  
the entries originated from the same publisher before considering  
them to be duplicates.


How is this a Denial of service attack? Isn't it just ordinary  
spoofing/impersonation?


Apart from that, +1.


Yeah, it seems like it can't possibly be wrong to highlight this  
risk, which I at least didn't notice until someone pointed it out to  
me, so I bet others will miss it too.  -Tim




Re: atom:type, xsl:output

2005-05-24 Thread Tim Bray


On May 24, 2005, at 1:25 AM, Graham wrote:


First off: it is an error to lie about your
media-type, so I would change SHOULD be suitable for
handling as the indicated media type to MUST be
suitable for handling as the indicated media type.



+1


I'm tempted to agree but can't, because the condition of being  
suitable for handling as is not deterministic and testable enough to  
merit a MUST. -Tim




Re: extension elements inside link elements?

2005-05-24 Thread Tim Bray


On May 24, 2005, at 10:43 AM, Graham wrote:

I also think removing that piece of text makes it unclear that the  
element is normally empty.


+1 -Tim



Author and contributor

2005-05-23 Thread Tim Bray


co-chair-modeWe observe a significant amount of discomfort with the  
current one-author/multiple-contributors model in atom-format.   
Despite the mentions that Rob dug up, nobody can claim this has had  
serious in-depth discussion in the IETF context.


On the other hand, we note that the current setup does have a  
coherent logical grounding, namely adopting Dublin Core semantics by  
identifying a singular primary-creator role and a plural contributor  
role.  If we leave things the way they are, a pointer to this  
derivation would improve the draft.


However, aside from Rob Sayre, nobody has been particularly militant  
in defending the current setup.  Personally I don't think any of the  
alternatives proposed are going to have fewer corner cases, but quite  
likely they won't have more either.


Unfortunately, among those who want to change the current setup, we  
do not observe consensus on the subject of what to change them to.   
Near as we can tell, people want to make atom:author plural, some  
want to nuke atom:contributor and others don't.


If, in the next couple of days, a large number of people can coalesce  
behind ONE SPECIFIC change to the spec in this area, and there is no  
significant body of resistance to this change, Paul and I are  
prepared to be convinced that rough consensus exists for such a  
change./co-chair-mode




Re: atom:type, xsl:output

2005-05-23 Thread Tim Bray


On May 23, 2005, at 2:43 AM, Graham wrote:


* When @type=html then the content of the element is a xsd:string
[1] of an HTML DIV element plus optional insignificant whitespace
around it.  Which version of HTML is defined?  How do you
differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or
nonstandard HTML (like with marquee elements)?


I believe the answer would be street HTML, not any specific version.


Agreed.  What it says is SHOULD be suitable for handling as HTML.   
I.e. can be passed to your local HTML rendering control, which is  
doubtless a forgiving tag-soup engine. -Tim




Re: PaceClarifyAuthorContributor posted

2005-05-23 Thread Tim Bray



On May 23, 2005, at 5:18 AM, Graham wrote:



On 23 May 2005, at 1:09 pm, Robert Sayre wrote:



Fully disagree. Try a record album by the Rolling Stones or
Grandmaster Flash and The Furious 5. OK to list the band members as
contributors? Definitely.



Maybe there's a minor bug in the wording here


Uh, Graham, I thought your Pace did a good job of capturing the  
consensus that seems to be emerging, and then slipped in just a  
little extra with the name-duplication rules.  I'm with Rob, that  
stuff is past the 80/20 point, I'd suggest you pare down the Pace as  
a friendly amendment. -Tim




  1   2   3   >