RE: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
I would like to have application/atomentry+xml for entry. As a result, application/atom+xml must be a feed. 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry When the media type is used without the type parameter, type=feed is assumed. This cause is ok, but a bit complicated. We have already had a charset parameter. If using both the type and the charset parameters together, then the Content-Type header will be application/atom+xml; type=feed; charset=utf-8. If type parameter is not declared, then type=feed is assumed because most feeds are serving with application/atom+xml with or without the charset parameter today. Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer Sent: Wednesday, November 29, 2006 16:04 To: Atom-Syntax Subject: Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless) 2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the updated media-type fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
RE: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
Why is one of the normative references in draft draft-ietf-atompub-format-11 instead of RFC4287? Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Tuesday, November 28, 2006 00:53 To: atom-syntax; atom-protocol Subject: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt] All: With Phil Rignalda's permission, I have taken over the role of editor for the Autodiscovery draft and at Lisa and Paul's suggestion I have resubmitted the draft as an **individual** submission (as opposed to a Working Group Draft). Phil has requested that his name be removed from the draft. The process for moving forward on this spec will be the same as with Atom and APP. Change proposals will need to be submitted in the form of Pace's on the wiki with a copy sent to atom-syntax. Pace's need to include spec ready text, when appropriate. When consensus emerges around a particular pace, it will get incorporated into the draft. Editorial changes need not go through this process; just post a note to the atom-syntax list and I'll make sure the change is made. - James Original Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Atom Feed Autodiscovery Author(s) : M. Pilgrim, J. Snell Filename: draft-snell-atompub-autodiscovery-00.txt Pages : 14 Date: 2006-11-27 This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the link element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-snell-atompub-autodiscovery-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-snell-atompub-autodiscovery-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
RE: PaceResurrectAutodiscovery
Your example is a invalid HTML document. link can only be put inside head. While you have mentioned HTML 5, you may take a look on XHTML 2. XHTML 2 allows all elements inside body to have a href attribute and thus they can be a link without using a. It is very complicated case for UAs to scan all. IE 7 is actually doing a good job, it is rejecting all link elements which are put in a wrong position. I cannot understand why Firefox, Opera and Safari detect the links. Franklin Tse -Original Message- From: Lachlan Hunt [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 22:24 To: Tse Shing Chi (Franklin/Whale) Cc: 'atom-syntax' Subject: Re: PaceResurrectAutodiscovery Tse Shing Chi (Franklin/Whale) wrote: 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. Ah, but this works! html head titleFeed Autodiscovery/title /head body p... really long body .../p link rel=alternate type=application/atom+xml href=/feed /body /html I tested that with both HTML and XHTML and both tests worked in Firefox, Opera and Safari. IE7 was the only broswer that appeared to do what you suggest, at least to some degree. But given that IE7 is in the minority in this case, and doesn't handle link elements in the body like other browsers (the way it's being defined in HTML5), I consider that a bug in IE. -- Lachlan Hunt http://lachy.id.au/
RE: Fwd: PaceResurrectAutodiscovery
Parse Error! [ http://www.whatwg.org/specs/web-apps/current-work/#parse ] Quote The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Saturday, November 25, 2006 23:59 To: Geoffrey Sneddon Cc: atom-syntax@imc.org Subject: Re: Fwd: PaceResurrectAutodiscovery Geoffrey Sneddon wrote: The link element is currently defined as being able to used In a head element. in HTML5, in the current WD. I was referring to the way browsers have to handle it in non-conforming documents. | If the insertion mode is in body |Handle the token as follows: |... |A start tag token whose tag name is one of: base, link, meta, |style, title |Parse error. Process the token as if the insertion mode had |been in head. That effectively means, no matter where the link element occurs, it has to be inserted into the head. http://www.whatwg.org/specs/web-apps/current-work/#in-body -- Lachlan Hunt http://lachy.id.au/
RE: PaceResurrectAutodiscovery
No. Authors take the responsibility to correct the mistakes. Browsers should not help them to do so. I would like to repeat once again: HTML 4.01, HTML 5, XHTML 1.0 and XHTML 1.1 allow link elements put inside the head section only. Even though the behavior of Internet Explorer 7 is inconsistent, it can handle valid examples, it is the most important point. I cannot imagine if meta and title are being used anywhere in a HTML document. Franklin Tse -Original Message- From: Lachlan Hunt [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 23:57 To: Tse Shing Chi (Franklin/Whale) Cc: 'atom-syntax' Subject: Re: PaceResurrectAutodiscovery Tse Shing Chi (Franklin/Whale) wrote: Lachlan Hunt wrote: Ah, but this works! html head titleFeed Autodiscovery/title /head body p... really long body .../p link rel=alternate type=application/atom+xml href=/feed /body /html Your example is a invalid HTML document. link can only be put inside head. That's not the point. In the real world, authors make many stupid mistakes and elements appear all over the place, which browsers have to deal with. While you have mentioned HTML 5, you may take a look on XHTML 2. XHTML 2 allows all elements inside body to have a href attribute and thus they can be a link without using a. It is very complicated case for UAs to scan all. XHTML 2 effectively dead. That href-on-any-element feature is one that browser vendors have already stated to be difficult to implement. In fact, XHTML 2 as a whole is already near impossible to implement in the real world, and, if the WG goes through with their stated plan to reuse the XHTML 1.x namespace, it will be totally impossible to implement. Therefore, XHTML 2 is irrelevant to this discussion. IE 7 is actually doing a good job, it is rejecting all link elements which are put in a wrong position. No, IE's behaviour is extremely inconsistent and buggy. This test actually works in IE. !DOCTYPE html titleAutodiscovery/title div link rel=alternate type=application/atom+xml href=http://lachy.id.au/log/feed; pThis case still works in IE! /div I cannot understand why Firefox, Opera and Safari detect the links. Because they have to deal with real world content. For example, although this isn't a an autodiscovery link, see where Google have placed the prefetch link in this page. http://www.google.com/search?q=Microsoft link rel=prefetch href=http://www.microsoft.com/; Because browsers have to handle all link elements the same way, regardless of their attributes, they also have to handle the equivalent for autodiscovery links. -- Lachlan Hunt http://lachy.id.au/
RE: PaceResurrectAutodiscovery
Sorry, browsers have to deal with the infinite number of legacy documents that already make an infinite number of mistakes. Significantly changing that behaviour is just not possible. The IE team is correcting this kind of mistakes: http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx. It is possible that link and meta in places other than head may not get parsed in the future. Here's one example. http://au.lge.com/ Horrible! meta http-equiv=Content-Type content=text/html; charset=UTF-8 inside a table. But... meta name=description and meta name=keywords are in a correct location. Franklin Tse -Original Message- From: Lachlan Hunt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 26, 2006 00:38 To: Tse Shing Chi (Franklin/Whale) Cc: 'atom-syntax' Subject: Re: PaceResurrectAutodiscovery Tse Shing Chi (Franklin/Whale) wrote: No. Authors take the responsibility to correct the mistakes. Browsers should not help them to do so. Sorry, browsers have to deal with the infinite number of legacy documents that already make an infinite number of mistakes. Significantly changing that behaviour is just not possible. However, this is getting way off topic for this list. If you have an issue with the way HTML5 error handling is being defined, I suggest you raise the issue on the WHATWG mailing list. I cannot imagine if meta and title are being used anywhere in a HTML document. Here's one example. http://au.lge.com/ Note the meta element that occurs within a table, of all places! -- Lachlan Hunt http://lachy.id.au/
RE: PaceResurrectAutodiscovery
== Correction == The IE team is correcting this kind of mistakes: http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx. It should be The IE team is removing support to this kind of mistakes Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tse Shing Chi (Franklin/Whale) Sent: Sunday, November 26, 2006 00:50 To: 'Lachlan Hunt' Cc: 'atom-syntax' Subject: RE: PaceResurrectAutodiscovery Sorry, browsers have to deal with the infinite number of legacy documents that already make an infinite number of mistakes. Significantly changing that behaviour is just not possible. The IE team is correcting this kind of mistakes: http://blogs.msdn.com/ie/archive/2005/08/29/457667.aspx. It is possible that link and meta in places other than head may not get parsed in the future. Here's one example. http://au.lge.com/ Horrible! meta http-equiv=Content-Type content=text/html; charset=UTF-8 inside a table. But... meta name=description and meta name=keywords are in a correct location. Franklin Tse -Original Message- From: Lachlan Hunt [mailto:[EMAIL PROTECTED] Sent: Sunday, November 26, 2006 00:38 To: Tse Shing Chi (Franklin/Whale) Cc: 'atom-syntax' Subject: Re: PaceResurrectAutodiscovery Tse Shing Chi (Franklin/Whale) wrote: No. Authors take the responsibility to correct the mistakes. Browsers should not help them to do so. Sorry, browsers have to deal with the infinite number of legacy documents that already make an infinite number of mistakes. Significantly changing that behaviour is just not possible. However, this is getting way off topic for this list. If you have an issue with the way HTML5 error handling is being defined, I suggest you raise the issue on the WHATWG mailing list. I cannot imagine if meta and title are being used anywhere in a HTML document. Here's one example. http://au.lge.com/ Note the meta element that occurs within a table, of all places! -- Lachlan Hunt http://lachy.id.au/
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/
RE: Forward Compatibility
Atom processors need to know how to construct a full XHTML 1.x document from the Atom entry if they co-operate with an XHTML 1.x processing module that wants to see full documents. It seems that... only extremely few of atom processors can do so at the moment... (Actually I am not sure if there is any) Microsoft Office Outlook 2007, Mozilla Thunderbird 1.5.0.8 and Opera 9.1.8653 all fails to generate a full XHTML 1.x document. Office shows a HTML document with div xmlns=http://www.w3.org/1999/xhtml;p xmlns=http://www.w3.org/1999/xhtml;img ... //p/div. Thunderbird is better... at least... does not have any xmlns=... but XHTML's elements... such as br /, img ... /... still exists... Opera has !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; in its generated source... with XHTML's elements like Thunderbird... It seems that... even type=xhtml... is lacking support from processors. Franklin Tse -Original Message- From: Henri Sivonen [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 21, 2006 05:28 To: Tse Shing Chi ((Franklin/Whale)) Cc: atom-syntax@imc.org Subject: Re: Forward Compatibility On Nov 20, 2006, at 17:47, Tse Shing Chi ((Franklin/Whale)) wrote: I understand your not wanting to put a complete XHTML 2.0 document inside atom:content or atom:summary, but since DIV isn't supposed to be the root element of an XHTML 2.0 document, omitting the rest of the document violates at least the spirit of the Atom spec...though we didn't use normative language where it says normally to actually prohibit it. But div is not the root element of XHTML 1.x as well. It isn't, but XHTML 1.x as type='xhtml' is a special case in Atom, so Atom processors need to know how to construct a full XHTML 1.x document from the Atom entry if they co-operate with an XHTML 1.x processing module that wants to see full documents. Using an XHTML 1.x fragment with type='application/xhtml+xml' would not be proper. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
RE: PaceResurrectAutodiscovery
Web Apps 1.0 is already defining it 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. 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 ] If we need to define more link type, we may need to do the following as recommended by the specification. 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. On the other hand, the W3C Widgets 1.0 autodiscovery is also using alternate. [ http://www.w3.org/TR/widgets/#autodiscovery ] The spec should not require that autodiscovery only work for link elements. The rel and type attributes may also be used on a elements and, although not all existing UAs currently support that, the spec should define that either link or a may be used. I think that only link should be used. All feeds linked by a should be ignored during the process of autodiscovery. Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Friday, November 24, 2006 12:52 To: atom-syntax Subject: Re: PaceResurrectAutodiscovery James M Snell wrote: Pace to put autodiscovery back in play [1] Resubmit the Autodiscovery Draft[2] with no changes and submit for consideration as a Proposed Standard. I don't think that's a good idea for several reasons, primarily because feed autodiscovery isn't just for Atom, it's for RSS, RDF and other syndication formats as well; the quality of the spec is poor; and, as Henri pointed out, Web Apps 1.0 is already defining it. See below for a more detailed explanation. Eric Scheid wrote: I suggest a relationship value of feed, to use when pointing to a feed. I agree. James M Snell wrote: My preference would be to maintain the de facto standard that is already in use by countless sites. I'm just as annoyed as you are about the ambiguity in the mime type but in this case I think what's currently deployed trumps what's technically correct. I agree that compatibility with existing practice is important, but that doesn't mean the situation can't be improved in a backwards compatible way. Thomas Broyer wrote: Henri Sivonen wrote: The latest WA 1.0 draft covers this as follows: If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. http://whatwg.org/specs/web-apps/current-work/#alternate0 This conforts me in thinking that the application/atom+xml media type should be updated to add a type parameter with values feed and entry. For the user, why would such a distinction be useful? Also, given what the WA1 says about rel=alternate feed: If the alternate link type is also specified, then the feed is specifically the feed for the current document Then wouldn't that have effectively the same meaning when used on an individual article's page? The feed keyword indicates that the referenced document is a syndication feed. Being a syndication feed is expressed by the media type, there's no need for a 'rel' value. No, the MIME type only indicates the format, not the type of relattionship. http://ietfreport.isoc.org/idref/draft-ietf-atompub-autodiscovery/ The sections Syntax rules inherited from HTML and Syntax rules inherited from XHTML are not useful. In the case of XHTML, the syntax is defined by XML. In the case of HTML, the syntax is defined in HTML4 (though it's being redefined in HTML5). It is not necessary for this spec to provide a summary of the syntax rules, although it may do so informatively, it should instead normatively refer to the HTML 4.01, XHTML 1.0, XML 1.0 and/or (X)HTML5 specs. The value of the rel attributes are being defined in Web Applications 1.0, as Henri pointed out already. The spec should not mandate the use of alternate for syndication feeds, but rather define feed and specify the conditions under which alternate implies feed (for backwards compatibility). That is what WA1 does. When rel=feed is used, the type attribute should not be required, and it most certainly must not specify specific MIME type to use. There are various syndication formats in use, including Atom,
RE: Author element best practice
Section 4.2.1 of RFC 4287: If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above. In case there isn't any author, anonymous seems to be a good choice. Anyway, it is just what my thought. Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Wednesday, November 22, 2006 19:11 To: atom-protocol; atom-syntax Subject: Author element best practice Hi folks, Quick question regarding the atom:author element in a member resource. Say I POST an atom:entry to a collection URI, this entry does not have an atom:author (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
RE: The src attribute of atom:content
There is an unexpected reply located in http://www.imc.org/atom-protocol/mail-archive/msg07722.html. Quote: atom:content type=image/svg+xml.../atom:content I don't know how to display such a content within a widget, however I know there is some program in the registry (Windows Registry, Freedesktop's shared MIME database, OS X configuration, etc.) which is able to open it; so I whot the summary (if any) and provide Open with... and Save as... buttons. I couldn't do that with an xhtml:object embeded in an atom:content type=xhtml/ (or eventually type=html). It is almost what I want aggregators to do actually. However, web-based aggregators may have difficulties in handling it. Currently, the way to provide alternate format or text... seems to be the followings. For examples: summary type=xhtml div xmlns=http://www.w3.org/1999/xhtml; object type=image/svg+xml data=http://www.w3.org/Icons/valid-svg11-v.svg; !-- alternate format, alternate text -- img src=http://www.w3.org/Icons/valid-svg11.png; alt=Valid SVG 1.1 / /object /div /summary content type=image/svg+xml src=http://www.w3.org/Icons/valid-svg11-v.svg; / summary type=xhtml div xmlns=http://www.w3.org/1999/xhtml; object type=application/pdf data=http://www.w3.org/TR/xhtml11/xhtml11.pdf; !-- alternate format -- object type=text/html data=http://www.w3.org/TR/xhtml11/; !-- alternate text -- p.../p /object /object /div /summary content type=application/pdf src=http://www.w3.org/TR/xhtml11/xhtml11.pdf; / Anyway, no one can ensure that aggregators will display the summary when they are able to show the content. Also, I would like to repeat again, my examples are not the correct use of summary. If you have any comment, please reply to atom-syntax@imc.org Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Wednesday, November 22, 2006 04:07 To: atom-syntax@imc.org Subject: Re: The src attribute of atom:content * Tse Shing Chi (Franklin/Whale) [EMAIL PROTECTED] [2006-11-20 11:15]: That's the problem. Since there is no defined fallback mechanism, the actual mechanism varies from application to application. Authors of Atom feeds cannot expect what feed readers will do, and they are not given a chance to provide alternate content in a different format. I agree, after all the discussion, that this an aspect of Atom that could have been better. I doubt anyone forsaw any need for this at the time. For the time being, you’ll have to make do with using atom:summary as alternative text. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Forward Compatibility
First of all, the media type should still be application/xhtml+xml for XHTML 2.0, although application/xml or even text/html may be used. I don't think whole XHTML 2.0 document needs to be contained in the content or summary element, it is too complicated. Using the div element is still a suitable way (div is remained in XHTML 2.0 without major changes, http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_div) I think. For browsers' implementation, in fact, XHTML 1.1 is still not well-supported. CSS 2 is another example of poor implementation by browsers. I do think that Atom should not be easy to change or be updated very frequently. That's why Atom should leave some extents of forward compatibility. Franklin -Original Message- From: Henri Sivonen [mailto:[EMAIL PROTECTED] Sent: Sunday, November 19, 2006 17:43 To: Tse Shing Chi ((Franklin/Whale)) Cc: Atom Syntax Subject: Re: Forward Compatibility On Nov 19, 2006, at 04:33, Tse Shing Chi ((Franklin/Whale)) wrote: This means that XHTML 2 contents can be used as follows? content type=xhtml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content content type=application/xhtml+xml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content By the way, are they the same? They are not the same and neither is correct. The correct way would be: content type=application/xml html xmlns=http://www.w3.org/2002/06/xhtml2/; head titleThe title of the entry again/title /head body !-- Contents XHTML 2.0 -- /body /html /content But it isn't worthwhile to spend energy on this issue. Browser vendors have been ignoring XHTML 2.0 and now even the W3C itself is moving aside the group that has been working on the XHTML 2.0 spec. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
The src attribute of atom:content
I recently tried to make a feed acting as a linking page. I am impressed by the src attribute of atom:content. Then I made a feed entry as follow. entry titleExample Title/title idhttp://www.example.org//id content type=text/html src=http://www.example.org/; / published2006-11-19T13:05:00Z/published updated2006-11-19T13:05:00Z/updated /entry Unfortunately, numbers of feed aggregators will not follow the src attribute probably due to security reasons. While I want to provide alternate text, I cannot find a way to do so since the specification of Atom mentioned, 'If the src attribute is present, atom:content MUST be empty.' As a result, I use atom:summary. entry titleExample Title/title idhttp://www.example.org//id link rel= summary type=xhtml div xmlns=http://www.w3.org/1999/xhtml; pPlease proceed to a href=http://www.example.org/;http://www.example.org//a for contents./p /div /summary content type=text/html src=http://www.example.org/; / published2006-11-19T13:05:00Z/published updated2006-11-19T13:05:00Z/updated /entry However, it is actually an abuse of atom:summary because the atom:summary element is a Text construct that conveys a short summary, abstract, or excerpt of an entry. More unfortunately, feed aggregators will not consider this entry is linking to http://www.example.org/ even though the content is external. As a result, atom:link is added. entry titleExample Title/title idhttp://www.example.org//id link rel=alternate type=text/html href=http://www.example.org/; / summary type=xhtml div xmlns=http://www.w3.org/1999/xhtml; pPlease proceed to a href=http://www.example.org/;http://www.example.org//a for contents./p /div /summary content type=text/html src=http://www.example.org/; / published2006-11-19T13:05:00Z/published updated2006-11-19T13:05:00Z/updated /entry I did not imagine how complicated the situation is. And after doing so many things, content type=text/html src=http://www.example.org/; / is proved to be useless. However, I do hope that it is useful. The followings are my thoughts. 1. When the src attribute of atom:content is present, it includes the meaning of having an alternate link to the same URI inside src. 2. atom:content SHOULD NOT be empty. I think that atom:content is something like xhtml:object. Alternate contents should be put inside the element. For examples: content type=text/html src=http://www.example.org/; content type=xhtml div xmlns=http://www.w3.org/1999/xhtml; pPlease proceed to a href=http://www.example.org/;http://www.example.org//a for contents./p /div /content /content Or content type=text/html src=http://www.example.org/; alternatetype=xhtml div xmlns=http://www.w3.org/1999/xhtml; pPlease proceed to a href=http://www.example.org/;http://www.example.org//a for contents./p /div /content I do think providing alternate content is important. Franklin Tse
RE: The src attribute of atom:content
The spec. mentioned, Atom Processors MAY choose to ignore remote content. However, there is no instructions or guidelines for aggregators to follow about what they should do when they choose not to load the external content. You can accomplish what you're trying to do by throwing in an alternate link, using the summary element and dropping the content. Yes, I can. But what is the use of atom:content/@src then? The src attribute can be removed from the spec if it is the case. Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Monday, November 20, 2006 01:20 To: Tse Shing Chi (Franklin/Whale) Cc: atom-syntax@imc.org Subject: Re: The src attribute of atom:content The spec can be changed, it's just not a great idea to do so until we get a critical mass of issues that can't seem to be adequately worked around. You can accomplish what you're trying to do by throwing in an alternate link, using the summary element and dropping the content. entry titleExample Title/title idhttp://www.example.org//id summaryA simple explanation of quantum entaglement/summary link type=text/html src=http://www.example.org/; / published2006-11-19T13:05:00Z/published updated2006-11-19T13:05:00Z/updated /entry However, you should do as Aristotle suggests and file a bug report with any aggregator that does not support the content/@src attribute. - James Tse Shing Chi (Franklin/Whale) wrote: Why can't change the specification? It is currently a proposed standard only. I still think that providing alternate content is very important... at least... add an alt attribute to atom:content as if xhtml:img... Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Monday, November 20, 2006 00:15 To: atom-syntax@imc.org Subject: Re: The src attribute of atom:content * Tse Shing Chi (Franklin/Whale) [EMAIL PROTECTED] [2006-11-19 16:05]: Unfortunately, numbers of feed aggregators will not follow the src attribute probably due to security reasons. atom:content/@src is indeed not well supported. Many aggregators aren’t even aware of the attribute and don’t do even as much as showing a link to the external content. This is broken; please file a bug against the aggregator in question. However, it is actually an abuse of atom:summary because the atom:summary element is a Text construct that conveys a short summary, abstract, or excerpt of an entry. Agreed. More unfortunately, feed aggregators will not consider this entry is linking to http://www.example.org/ even though the content is external. This is correct and by design (though implementation correctness here is probably often by accident; see above). The followings are my thoughts. 1. When the src attribute of atom:content is present, it includes the meaning of having an alternate link to the same URI inside src. 2. atom:content SHOULD NOT be empty. I think that atom:content is something like xhtml:object. Alternate contents should be put inside the element. We could discuss whether these ideas would have been worthwhile. However, this is moot, as the spec is done and cannot be changed. Since these suggestions are incompatible with RFC 4287, they cannot be recommended as best practices either. Sorry. :-( Regards,
Forward Compatibility
Currently, there is no “version” element or attribute to reflect the current version of Atom using in an Atom feed. Does it mean that there will not be any new version of Atom? On the other hand, the specification mentioned “If the value of type is xhtml, the content of atom:content MUST be a single XHTML div element and SHOULD be suitable for handling as XHTML.”. At the moment, both XHTML 1.0 and 1.0 are sharing the same XML Namespace of http://www.w3.org/1999/xhtml. However, XHTML 2.0 will have a new namespace http://www.w3.org/2002/06/xhtml2/, and the chance of having more future versions of XHTML cannot be eliminated. Have Atom prepared for this? Franklin Tse
Forward Compatibility
I am sorry that I have sent an e-mail in HTML format. This is the plain text version, which has the same contents with the HTML version sent before. Currently, there is no version element or attribute to reflect the current version of Atom using in an Atom feed. Does it mean that there will not be any new version of Atom? On the other hand, the specification mentioned “If the value of type is xhtml, the content of atom:content MUST be a single XHTML div element and SHOULD be suitable for handling as XHTML.”. At the moment, both XHTML 1.0 and 1.0 are sharing the same XML Namespace of http://www.w3.org/1999/xhtml;. However, XHTML 2.0 will have a new namespace http://www.w3.org/2002/06/xhtml2/;, and the chance of having more future versions of XHTML cannot be eliminated. Have Atom prepared for this? Franklin Tse
RE: Forward Compatibility
This means that XHTML 2 contents can be used as follows? content type=xhtml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content content type=application/xhtml+xml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content By the way, are they the same? Franklin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Sunday, November 19, 2006 03:20 To: Mark Nottingham Cc: Tse Shing Chi ((Franklin/Whale)); atom-syntax@imc.org Subject: Re: Forward Compatibility Mark Nottingham wrote: [snip] ...new metadata can be added using extensions, rather than by versioning Atom. It's also possible for new RFC's to update the current Atom namespace in a backwards compatible way without deprecating/obsoleting RFC4287. However, XHTML 2.0 will have a new namespace http://www.w3.org/2002/06/xhtml2/;, and the chance of having more future versions of XHTML cannot be eliminated. Have Atom prepared for this? This was intentional; if we allowed future, non-backwards compatible versions of HTML to appear in the same places that XHTML1 content is allowed, processors wouldn't know what to do with it unless they understood XHTML2. Tying the allowed content to a specific version of XHTML promotes interoperability. That said, Atom can currently carry XHTML2 by specifying the media type and properly declaring the namespace. - James
RE: Forward Compatibility
Actually, all XHTML 1.0, 1.1 and 2.0 are members of the XHTML family. They, of course, can be carried by type=application/xhtml+xml. But it is quite confusing that type=xhtml must be XHTML 1.0 or 1.1. Franklin -Original Message- From: James M Snell [mailto:[EMAIL PROTECTED] Sent: Sunday, November 19, 2006 11:30 To: Tse Shing Chi (Franklin/Whale) Subject: Re: Forward Compatibility Tse Shing Chi (Franklin/Whale) wrote: This means that XHTML 2 contents can be used as follows? content type=xhtml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content Not this one. When type=xhtml you must use XHTML 1.0 or 1.1 content type=application/xhtml+xml div xmlns=http://www.w3.org/2002/06/xhtml2/; !-- Contents XHTML 2.0 -- /div /content This should be fine. - James
