Re: PaceResurrectAutodiscovery
Tse Shing Chi (Franklin/Whale) wrote: However, since the Web Applications draft already covers all of these issues fairly well, I believe it is unnecessary for this draft to be resurrected. Instead, a few of the good ideas from this draft should be integrated into the WA1 spec. Web Applications 1.0 is new markup language based on HTML under development. UAs that support feed autodiscovery are not necessary to support Web Apps 1.0. Relying on the definitions in the specification of Web Apps 1.0 is not appropriate. They don't need to support it fully, UAs can just implement the parts they need. The relationships can still be defined within it, just like many were defined in HTML4. The reason of using alternate is that, alternate was already defined the HTML 4.01 Specificiation and it is widely used by UAs. [ http://www.w3.org/TR/html401/types.html#type-links ] I'm aware of the reason for choosing alternate originally and I accept that it needs to be supported like that for backwards compatibility, but that doesn't mean we can't fix the mistake. Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details. The profile attribute isn't used in reality. Authors rarely set it, or it's set by their CMS to some default value and they don't bother to change it. Many of the tools that implement microformats don't even bother to check for the presence of the correct profile attribute, they just look for the values of the rel and class attributes. The profile attribute will most likely be dropped from HTML5. On the other hand, the W3C Widgets 1.0 autodiscovery is also using alternate. [ http://www.w3.org/TR/widgets/#autodiscovery ] That's currently a first working draft and I think that's a mistake, rel=alternate is not designed as a relationship for everything, it was designed for the specific purpose of linking to alternative representations. In the case of feeds, it sort of fits the definition, though not completely, but it certainly doesn't in the case of a widget. They should instead define something like rel=widget because a widget is not necessarily an alternate representation of a document. I think that only link should be used. All feeds linked by a should be ignored during the process of autodiscovery. Why? -- Lachlan Hunt http://lachy.id.au/
Re: PaceResurrectAutodiscovery
On Nov 24, 2006, at 10:28, Thomas Broyer wrote: My main problem with autodiscovery is this use case: the following links on an entry page in a blog-like scenario, where comments on the entry are shown at the bottom of the page: link rel=alternate type=application/atom+xml title=A standalone Atom Entry alternate representation, might even be updatable using HTTP PUT / ... 1. the first one should not be seen as a feed link; That ship sailed long ago. For backwards compatibility, UAs will treat links like the one quoted above as feed autodiscovery links-- not as standalone APP editing links. It is too late to apply elegance retroactively. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceResurrectAutodiscovery
2006/11/24, Henri Sivonen: On Nov 24, 2006, at 10:28, Thomas Broyer wrote: My main problem with autodiscovery is this use case: the following links on an entry page in a blog-like scenario, where comments on the entry are shown at the bottom of the page: link rel=alternate type=application/atom+xml title=A standalone Atom Entry alternate representation, might even be updatable using HTTP PUT / ... 1. the first one should not be seen as a feed link; That ship sailed long ago. For backwards compatibility, UAs will treat links like the one quoted above as feed autodiscovery links-- not as standalone APP editing links. It is too late to apply elegance retroactively. …except if you update application/atom+xml to add a type=entry parameter... in which case the existing code will probably won't find the link... In the absence of 'type' parameter, you have no mean to know whether the Atom DOcument is a feed or entry, so you treat it as a possible feed, just in case. And you're backwards compatible. -- Thomas Broyer
Re: PaceResurrectAutodiscovery
On Nov 23, 2006, at 22:42, Henry Story wrote: This is very nice, in that it opens up the possibility of placing good RDF descriptions of these links at the http://www.iana.org/ assignments/relation/, How could new link relations be described in RDF to such a degree that the description would actually be useful for software processing but simple enough to actually be implemented? Is it realistic to have UAs whacking IANA server effectively performing a DDoS on it? as well as making the link relation very extensible (people who want to try out new link relations, can just use their own, unambiguous url). How are full URIs distinguished from strings that need to be appended to http://www.iana.org/assignments/relation/; to obtain the full URI? Are UAs supposed to look for a colon as with XForms input methods? Where is this specified? In practice people seem to want to use one-word link relations even when they are coming up with their own. I would recommend you adopt that too. Perhaps you can even adopt the iana name space. If we could get them to put the appropriate rdf document at that location, people who created/coined new link relations could describe these relations as being superproperties or subroperties of relations the browser already knows, which would allow the browser to partially interpret those. Well, RDF is not viewed that favorably by the WHATWG. Also, the barrier for entry for the IANA registration process is likely too high. (It certainly is for MIME types.) As for using the same namespace, the HTML5 definitions for the link types don't necessarily match the Atom definitions. Recently, a WHATWG-managed registry for HTML5 rel values has been discussed informally. The idea was that conformance checkers could consult an online registry instead of only allowing a fixed list of values or allowing everything. RDF is an overkill for this. Even XMDP isn't the simplest thing that could possibly work. The simplest thing that could possibly work is a GETtable text/plain; charset=utf-8 resource at a well-known URI with one rel value per LF-separated line. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
RE: PaceResurrectAutodiscovery
I think that only link should be used. All feeds linked by a should be ignored during the process of autodiscovery. Why? Autodiscovery should be limited to head.../head. If an author wants his feeds to be discovered automatically by UAs, he should use link. Providing additional or same feed links using a is only for linking and does not affect the autodiscovery. Scanning whole document is not necessary and increases the complexity. Franklin Tse -Original Message- From: Lachlan Hunt [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 15:45 To: Tse Shing Chi (Franklin/Whale) Cc: 'atom-syntax' Subject: Re: PaceResurrectAutodiscovery Tse Shing Chi (Franklin/Whale) wrote: However, since the Web Applications draft already covers all of these issues fairly well, I believe it is unnecessary for this draft to be resurrected. Instead, a few of the good ideas from this draft should be integrated into the WA1 spec. Web Applications 1.0 is new markup language based on HTML under development. UAs that support feed autodiscovery are not necessary to support Web Apps 1.0. Relying on the definitions in the specification of Web Apps 1.0 is not appropriate. They don't need to support it fully, UAs can just implement the parts they need. The relationships can still be defined within it, just like many were defined in HTML4. The reason of using alternate is that, alternate was already defined the HTML 4.01 Specificiation and it is widely used by UAs. [ http://www.w3.org/TR/html401/types.html#type-links ] I'm aware of the reason for choosing alternate originally and I accept that it needs to be supported like that for backwards compatibility, but that doesn't mean we can't fix the mistake. Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details. The profile attribute isn't used in reality. Authors rarely set it, or it's set by their CMS to some default value and they don't bother to change it. Many of the tools that implement microformats don't even bother to check for the presence of the correct profile attribute, they just look for the values of the rel and class attributes. The profile attribute will most likely be dropped from HTML5. On the other hand, the W3C Widgets 1.0 autodiscovery is also using alternate. [ http://www.w3.org/TR/widgets/#autodiscovery ] That's currently a first working draft and I think that's a mistake, rel=alternate is not designed as a relationship for everything, it was designed for the specific purpose of linking to alternative representations. In the case of feeds, it sort of fits the definition, though not completely, but it certainly doesn't in the case of a widget. They should instead define something like rel=widget because a widget is not necessarily an alternate representation of a document. I think that only link should be used. All feeds linked by a should be ignored during the process of autodiscovery. Why? -- Lachlan Hunt http://lachy.id.au/
