Re: Autodiscovery Draft
John Panzer wrote: There were strong suggestions at the time, I think, that this was part of HTML and should belong to the WHAT-WG. So is there a WHAT-WG document to look at? Yes. http://www.whatwg.org/specs/web-apps/current-work/#link-type5 -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Current and permalink link rel values
A. Pagaltzis wrote: What’s the purpose of the `current` link? Is there ever a case where it would be bad to send the reader to the permanent location of the item? Yes, for some definitions of "bad". First of all many sites want to direct a user to the main page, and then have them click through to the full article (more space to show ads, more hits). Secondly, the permalink URLs don't necessarily exist (yet). The main URLs do. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Current and permalink link rel values
Antone Roundy wrote: Both of those would probably be best described as "alternate" links. The second one in particular is what "alternate" was intended to be used for. However, RFC 4287 contains the following: o atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values. Furthermore, a link element with no explicit rel attribute is assumed to be an alternate link, though I think this counts against the maximum of 1 given above. Consequently I suspect (though have not yet tested) that at least some feed readers pick the alternate link as the default when there's more than one. I suspect others pick the first in document order. Does anyone know how feed readers actually do choose among multiple possible links in an entry? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Current and permalink link rel values
I'd like to add multiple links to my feed for both the current version of the story and the permalink. E.g. Matt Mullenweg has released Wordpress 2.1.1 and 2.0.9. http://www.w3.org/1999/xhtml"; id="February_22_2007_30633" class="2007-02-22T09:31:33Z"> Matt Mullenweg has released href="http://wordpress.org/development/2007/02/new-releases/";>Wordpress 2.1.1 and 2.0.9. http://www.cafeconleche.org/#February_22_2007_30633"/> href="http://www.cafeconleche.org/oldnews/news2007February22.html#February_22_2007_30633"/> http://www.cafeconleche.org/#February_22_2007_30633 2007-02-22T09:31:33Z In particular is "rel='permalink'" a reasonable way to do this? Might it make sense to register current and permalink values for the rel attribute in the IANA Registry of Link Relations? Or something like them? By the way, http://www.iana.org/assignments/relation/ is 404. This is referenced in the Atom 1.0 spec. It doesn't really need to be resolved, but it would be nice to put something there. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Forward Compatibility
Mark Nottingham wrote: Atom has a namespace; that can be use to introduce new versions of the format. No, no, and no. We've been down this road before in other specs, and the community wisdom is that you do not rev the namespace just to introduce a new version. Doing so breaks a huge amount of the existing processing chain for an application. It is, of course, possible to introduce new elements in other namespaces; and the Atom spec does a much better than average job of preparing for this. Indeed there are already many interesting extensions. However, even if fundamental flaws were found in Atom 1.0 that required revisions and an Atom 1.1 or 2.0, the namespace should and almost certainly woulds remain the same. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Atom Export of source text
Alastair Rankine wrote: 4. All comments and trackbacks. For each comment or trackback: a. Source text This one needs to be expanded somewhat. In particular is it: A. The text of the entry as published in an Atom feed? or B. The source of that text as it appears in the original? In WordPress, for example, these two can be quite different. The real source is likely not HTML or XHTML, while the Atom output is. I recommend choosing A. I think it's the only one that has a chance of being interoperable. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Atom Export
Alastair Rankine wrote: Seems simple enough, but there's almost certainly some complexity that I'm overlooking. Yep. What if the images aren't subdirectories of the blog. e.g. Say we had a blog at http://example.com/foo/bar/blog which in turn referenced images at http://example.com/images/* and enclosures at http://example.com/enclosures/*, the resulting zipfile would contain: foo/bar/blog/index.xml images/1.jpg images/2.jpg ... enclosures/1.mp3 enclosures/2.mp3 Either you need to rewrite URLs are you need one new file at a know location, not present in the blog itself, to identify where the master index is. Or maybe not. xml:base attributes in the index.xml might be sufficient to straighten this all out. Indeed that might be necessary because different blog entries live at different URLs themselves. e.g. images/dog.png means one thing at http://example.com/blog/2006/Hello and another at http://example.com/blog/2005/Hello Perhaps it would be helpful to back up a step. Rather than starting with format design let's try to get a list of everything we need to include in this format. E.g. 1. Complete source text for every blog entry. 2. Metadata for each blog entry A. Title B. Catgeory C. Tags 3. All media referenced by relative URLs from blog entry 4. URL of blog entry What else? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Atom Syndication Format To Draft Standard?
Robert Sayre wrote: I think we should move the format to Draft Standard by clearing up any errata and adding two attributes: 'dir' and 'unicode-bidi', as defined in XHTML. Which elements would these be attached to? Also, I'm not familiar with the unicode-bidi attribute. Do you have a reference for it? Which version of XHTML is that in? Do you mean the CSS unicode-bidi property? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Atom Export
A. Pagaltzis wrote: Why the zip? Atom is an envelope format that can transport binary content. No, it isn't. An atom envelope can point to non-XML data binary data, but it cannot reasonably embed it. You could use an atomLink element to point to the binary data; then embed the whole file set in a zip file. Maybe that's all that really needed. However, you would need that extra level of packaging. I suppose you could base64 encode everything in a big atom:entry; but that's a lot of extra work for no particular point. It would essentially rule out using DOM to process this stuff, for example. Better to let MP3s, MPEGs, and other non-XML media to reside elsewhere and just let the XML point to it. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Atom Export
James M Snell wrote: Using XOP is definitely an option, but it's one that is likely to be far less efficient and likely quite a bit more complicated than a zip. Using the zip gives you quite a few options for exporting multiple collections, with associated resources, templates, configuration settings, plugins, whatever. Exporting the media resources is, at the very least, a very important requirement for the types of cases we'd be looking at to use this. XOP, if I understand it correctly, could in fact be packaged in a zip file, though no such packaging is described in the spec. If you went with a non-XOP zip as opposed to XOP, I suspect you'd probably end up reinventing a lot of XOP along the way. If you could get away with 20% of XOP, then it might be worthwhile to do something custom. Otherwise, I'd just go with XOP. Another possibility: OpenOffice does something very much like this (zipped XML + media). Does anyone know if that format is sufficiently generic to handle this use case? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: atom license extension (Re: [cc-tab] *important* heads up)
Karl Dubost wrote: IMHO, when the implementors do not understand the licenses, they have no rights to do things with content (because it's highly dependant of local laws) Ignorance of the law is no excuse. Implementors have the rights they have under the applicable set of laws, irrespective of whether or not they understand those rights. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: when should two entries have the same id?
James M Snell wrote: That's not quite accurate. Two entries with the same atom:id may appear within the same atom:feed only if they have different atom:updated elements. The spec is silent on whether or not two entries existing in *separate documents* may have identical atom:id and atom:updated values. They're ids, not guids. Certainly I would expect that there'll be some accidental conflicts. For instance one site might number its posts post1, post2, post3,...; and a different, unrelated site might do the same. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Copyright, licensing, and feeds
John Panzer wrote: I'm attempting to promote the use of explicit licenses in feeds, and Creative Commons is one great source of predefined licenses suitable for the kinds of things that people want to use feeds for today: Creative Commons only covers a very small subset of what's needed for feeds. It's completely inadequate for something as simple as "Don't republish this. Period." Much less if you want to say things like, "You can republish it but the cost is one cents per page view, and I have the right to audit your books once per year." -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Fyi, Apache project proposal
Sylvain Hellegouarch wrote: I'm sorry to ask but I'm not sure to understand the meaning of having an implementation which is exactly correct. As we have already seen on this list, RFC4287 lacks of precision in some context, therefore I wonder what being "exactly correct" represents. I believe Jigsaw [1] is a an example of what you mean. Sadly it seems to be hardly referenced anywhere. 1. It finds bugs in the spec. 2. When the spec isn't clear, the answer is "what the reference implementation does" Of course, this requires the reference implementation to be developed with the same authority that the spec writers have. That's not at all the case here, so I suspect "reference implementation" is a false statement. This will not be the reference implementation, and shouldn't call itself one. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: Fyi, Apache project proposal
James M Snell wrote: Just an FYI, http://wiki.apache.org/incubator/AriProposal http://www.snellspace.com/wp/?p=323 http://www.snellspace.com/public/ari.tar.gz We are proposing the creation of an Atom Reference Implementation project at Apache and have donated source to kick things off. I'm not sure if this is the right place for comments of this nature or not, but here goes. The one alarm bell that went off when i read this was Woodstox. That project has a history of nonconformance to XML. Is there any chance you could be convinced to throw that way in favor of a more correct STAX implementation such as Sun's? -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: Fyi, Apache project proposal
James M Snell wrote: We are proposing the creation of an Atom Reference Implementation project at Apache and have donated source to kick things off. What minimum Java version are you targetting? 1.2? 1.4? 5? -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: Fyi, Apache project proposal
James M Snell wrote: We are proposing the creation of an Atom Reference Implementation project at Apache and have donated source to kick things off. Currently the source fully implements RFC4287 and includes preliminary support for parsing APP introspection documents and the Feed Thread Extensions. Coming soon is APP client and server code. Could you elaborate a little more on what this actually is? For instance does it include a web server? or does it sit on top of one, and if so which? How would you describe this product to a programmer who is not familiar with the relevant RFCs and does not know what Atom is? -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: Licencing and feeds
John Panzer wrote: All -- I'm starting a discussion about feed licencing which might be of interest to members of this mailing list, and which will hopefully help form the technical extensions that AOL uses to deal with feed licencing. I'd welcome any input that this group may have. Directly relevant to this list, I'm tentatively advocating adopting James Snell's RelLicense extension for Atom, and looking for equivalent mechanisms for RSS. Link: http://journals.aol.com/panzerjohn/abstractioneer/entries/1281 Thank you! This is a very important discussion. I'm very glad to see AOL thinking about this. I'd love to comment on it. (Yes there are a few things you're missing to answer one of your questions.) But perhaps such an important discussion should happen somewhere that doesn't require annoying registration and pages of AOL legalese just to comment? As is I'll probably just put my comments up on my own blog and link to it from there. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: Datatype for IRIs in RELAX NG
I would recommend against using xsd:anyURI for IRIs. A URI is much more restrictive than an IRI, and one of the easiest things for a schema validator to check about an xsd:anyURI is that it only contains URI-legal ASCII characters. I think a new type is necessary if you do want to allow IRIs instead of simple URIs. I suspect you could do it with a regular expression but the syntax would be really hairy. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: partial xml in atom:content ?
Eric Scheid wrote: Is this a valid atom entry? [...elided...] a snippet of foo xml http://xmlns.com/foo/0.1/";> King George No. It's not even well-formed much less valid. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
Re: [Fwd: Re: todo: add language encoding information]
Henry Story wrote: The problem as I explained a little quickly in my mail yesterday, is that you are relating a entry and an id. Because there can be any number of entries with the same id it won't be clear which entry is the translation. I'm not sure if this is technically relevant or not, but in the case at hand neither entry is the translation, or alternately both are. Legally both are equally valid. This is customary in bi/multilingual jurisdictions and international treaties. For example, article 133 of the Geneva convention states: The present Convention is established in English and in French. Both texts are equally authentic. The Swiss Federal Council shall arrange for official translations of the Convention to be made in the Russian and Spanish languages. In that case, I suppose, neither English nor French is a translation but Russian and Spanish are. -- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
