Re: Feed History -04
On 01/10/2005 01:05, James Holderness wrote: Mark Nottingham wrote: Thanks for the feedback. As I've explained before, I have a pretty strong preference for the current design, to make it usable in other formats; i.e., the scope of this is not just Atom (which is why I'm probably going to do it as an Individual submission). At first I thought this was a good idea, but I'm starting to have second thoughts. The spec as it stands is fine for RSS 2, but I can see a lot of Atom people thinking that you should be using atom:link (as Henry suggested) and not wanting to corrupt their nice new format. No doubt the RSS 1 folks have their own preference for where this should be going and will probably be even more adamant that you do things the correct way (not sure what that might be - something using dc:relation maybe?) I would worry that if they don't like it, they won't use it. I think the RSS 1.0 folks would be happiest with a self-contained extension in its own namespace with each term having clear unambiguous semantics. I think Mark's design achieves this. Ian -- http://internetalchemy.org | http://purl.org/NET/iand Working on... Silkworm http://silkworm.talis.com/
Re: ACE - Atom Common Extensions Namespace
At 16:45 05/10/02, James M Snell wrote: http://www.w3.org/2005/Atom-extensions works for me... assuming, of course, that Those-Who-Officially-Assign-Such-Things go along with it. Tim and Paul know who to contact. The original .../ace URI was just a working thing pitched with full knowledge that it would likely change to something better. Good. I wanted to comment that I don't like ACE because the term is also used in the context of Internationalized Domain Names (where it stands for ASCII-compatible encoding). Regards,Martin.
Re: ACE - Atom Common Extensions Namespace
At 07:04 05/10/03, Walter Underwood wrote: --On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren [EMAIL PROTECTED] wrote: Having a file and folder of the same name is not technically possible. (Although you could emulate the effect of course with some mod_rewrite.) Namespaces aren't files, only names. Yes. But the W3C insists on having an actual file there, just for documentation at least, or ideally for some machine-readable information (schema,...). Also, some filesystem implementations do allow a file and a folder with the same name. Yes. The W3C server could certainly be tweaked to allow that, but it would be easier not to have to do that. Regards, Martin.
Re: ACE - Atom Common Extensions Namespace
I really like the ACE proposal, and I think the name is a good one too :-) It can't harm to have this option on the table now. No one is forced to use it. But I think it will have a few positive effects: - proposals that use it will have a cool ace namespace name - proposals that want to use the name will perhaps work a little harder to coordinate with other proposals on the table, which can't be a bad thing. Synergies between different proposals might be found thereby reducing the workload on implementors. - The namespace will act like a stamp of approval. It will be an indication that there is some consensus behind the proposal, and that things will play nice together This is not limiting anyone in any way. Proposals that want to use the dublin core, foaf or other namespaces should have no trouble using them. Proposals can also decide to use their own name space like the current feed history namespace. Henry Story On 3 Oct 2005, at 07:15, Mark Nottingham wrote: My .02, FWIW, and off the top of my head; I think this is a well-intentioned effort, but at the wrong end of the process. The market (i.e., users and implementors) should have a go at sorting out at what's common/prevalent enough to merit this sort of thing; having a co-ordinated namespace will lead to the problem of what to lump into it, how to version individual extensions within it, etc. And that is a problem that the end user won't to make himself all alone then. Since every end user is bound to come up with his own idea of how to lump things together, thereby creation an explosion of private lumps, this should in the end also reduce the workload on implementors. In other words, some of the benefits of Namespaces in XML -- e.g., loose coordination, well-insulated name spaces, ability to change namespace without changing local name to effect versioning -- will be lost, all for the sake of saving a few characters. Not worth it, IMO. Nothing is lost. All those benefits remain, as I said above. The atom spec has been designed to be open, the ace proposal will not and could not change that. A much better thing would be to wait a year or two and see if there's a need for such a beast. All these little proposals we have now indicates that we should work preventatively and at least put the option on the table for proposers to consider. And, the idea of an XML namespace backed by an IANA registry is a little bit twisted, considering the W3C and IETF's philosophies about these things ;) Cheers, On 01/10/2005, at 10:54 PM, James M Snell wrote: As I've been going through the effort of defining a number of Atom extensions, I've consistently come back to the thought that it would be interesting to explore the creation of a Common Extensions Namespace under which multiple standardized extensions can be grouped. I've written an initial draft of the concept but before I submit it as an Internet Draft, I'd like to get some feedback from the group. Please review the attached and let me know what you think. - James
Re: ACE - Atom Common Extensions Namespace
On Oct 2, 2005, at 11:15 PM, Mark Nottingham wrote: I think this is a well-intentioned effort, but at the wrong end of the process. The market (i.e., users and implementors) should have a go at sorting out at what's common/prevalent enough to merit this sort of thing; having a co-ordinated namespace will lead to the problem of what to lump into it, how to version individual extensions within it, etc. I have to agree with Mark. Consider this scenario: an extension gets added to ACE. Someone makes an extension that does the same thing differently. The market prefers the non-ACE method and adopts it more widely than the ACE solution. Now not only do you have multiple namespaces to declare, but one of them has a bunch of elements that don't get used, yet implementors feel compelled to implement them because they're part of this special namespace. Here's another scenario: an extension gets added to ACE, and another extension gets created that does the same thing better. Because the first has the ACE stamp of approval, the inferior method gets wide support, and the superior method dies. Both scenarios suggest that the market should be given time to choose best practices rather than some group deciding which practices are going to get special status in advance. If a feed is going to carry elements from a bunch of different extensions, it's going to be a relatively heavy feed anyway. The overhead of including multiple namespace declarations isn't going to be that great.
Re: ACE - Atom Common Extensions Namespace
* Antone Roundy [EMAIL PROTECTED] [2005-10-03 17:11]: The overhead of including multiple namespace declarations isn't going to be that great. I am coming around to the view that it doesn’t offer anything worthwhile. My own apprehension at lumping everything into a flat space, which led me to propose require element name prefixes, should have tipped me off. I’m kinda -0 on ACE now, because it doesn’t detract from anything, but then again that indifference is only symbolic, as I’m also -1 on putting the currently discussed extensions in this namespace, for the same reason. Saving a handful of bytes just doesn’t seem like a reasonable trade-off worth putting up with all the problems namespaces were designed to solve. This seems as misguided as my initial thrust with `rel=in-reply-to` for the comments extension to avoid a namespaced extension. I think it’s time (for me no less than others) to accept that doing things the XML way is sometimes verbose, and that the benefits of XML simply come at this price. Let’s do things the right way. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: ACE - Atom Common Extensions Namespace
Antone Roundy wrote: On Oct 2, 2005, at 11:15 PM, Mark Nottingham wrote: I think this is a well-intentioned effort, but at the wrong end of the process. The market (i.e., users and implementors) should have a go at sorting out at what's common/prevalent enough to merit this sort of thing; having a co-ordinated namespace will lead to the problem of what to lump into it, how to version individual extensions within it, etc. I have to agree with Mark. Consider this scenario: an extension gets added to ACE. Someone makes an extension that does the same thing differently. The market prefers the non-ACE method and adopts it more widely than the ACE solution. Now not only do you have multiple namespaces to declare, but one of them has a bunch of elements that don't get used, yet implementors feel compelled to implement them because they're part of this special namespace. Here's another scenario: an extension gets added to ACE, and another extension gets created that does the same thing better. Because the first has the ACE stamp of approval, the inferior method gets wide support, and the superior method dies. Both scenarios suggest that the market should be given time to choose best practices rather than some group deciding which practices are going to get special status in advance. If a feed is going to carry elements from a bunch of different extensions, it's going to be a relatively heavy feed anyway. The overhead of including multiple namespace declarations isn't going to be that great. All very excellent arguments... this is precisely the kind of feedback I was looking for. In order for ace to be successful, there would have to be a significant amount of effort put into making sure that the extensions that go into it are broadly supported and the best approach to the problem, neither of which we can do without significant implementation experience under our belts. At this point, as the author of the spec, I think it's safe for me to consider it a non-starter. thanks for the feedback! - James
Re: ACE - Atom Common Extensions Namespace
Martin Duerst wrote: At 07:04 05/10/03, Walter Underwood wrote: --On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren [EMAIL PROTECTED] wrote: Having a file and folder of the same name is not technically possible. (Although you could emulate the effect of course with some mod_rewrite.) Namespaces aren't files, only names. Yes. But the W3C insists on having an actual file there, just for documentation at least, or ideally for some machine-readable information (schema,...). Also, some filesystem implementations do allow a file and a folder with the same name. Yes. The W3C server could certainly be tweaked to allow that, but it would be easier not to have to do that. Hey wake up! If http://www.w3.org/2005/Atom maps to a file system folder, any web server that I know of will send a redirect to http://www.w3.org/2005/Atom/ and display the directory index file (index.html, default.htm, etc.) Moreover, there is precedence at w3.org to use URI without a trailing / as public identifiers (cool URIs?) when they actually are folders: See the last version links to CSS2 and DOM Level 2 recommendations: http://www.w3.org/TR/REC-CSS2 http://www.w3.org/TR/DOM-Level-2-Core http://www.w3.org/TR/DOM-Level-2-HTML http://www.w3.org/TR/DOM-Level-2-Style http://www.w3.org/TR/DOM-Level-2-Views … I really don't understand why you're discussing this sort of thing… We could really have an http://www.w3.org/2005/Atom/extensions namespace. -- Thomas Broyer
Next and Previous
What is the proper way to indicate the next chunk of articles in the feed? Is it [EMAIL PROTECTED] and if so what value for related? Where would someone put the offset? If this is not a good place for general Atom questions, please tell me which forum is more appropriate. Thank you. -- Alan Gutierrez - [EMAIL PROTECTED] - http://engrm.com/blogometer/
Re: ACE - Atom Common Extensions Namespace
Mark Nottingham wrote: My .02, FWIW, and off the top of my head; I think this is a well-intentioned effort, but at the wrong end of the process. The market (i.e., users and implementors) should have a go at sorting out at what's common/prevalent enough to merit this sort of thing; having a co-ordinated namespace will lead to the problem of what to lump into it, how to version individual extensions within it, etc. In other words, some of the benefits of Namespaces in XML -- e.g., loose coordination, well-insulated name spaces, ability to change namespace without changing local name to effect versioning -- will be lost, all for the sake of saving a few characters. Not worth it, IMO. -1 to ACE, for the very same reasons. -- Thomas Broyer
