Re: [uf-discuss] What to do when a microformat doesn't quite fit?
What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. But at the same time, it looks as if hAtom fits better than anything else. I was under the impression that most of these sorts of requirements are carried over from Atom itself, not things that hAtom invented. For example, the requirements on author as specified in RFC 4287: atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Thus, I suggest you use whatever solution you came up with for generating the actual Atom feeds. Your Atom feeds are valid Atom 1.0, aren't they? :-p I'm guessing the issue is less to do with hAtom and more to do with fitting your data into the Atom content model. I suppose putting yourself/the software as the feed author makes sense, as that is what created the feed. I'm less clear on the content issue. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. I was under the impression that most of these sorts of requirements are carried over from Atom itself, not things that hAtom invented. For example, the requirements on author as specified in RFC 4287: atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Thus, I suggest you use whatever solution you came up with for generating the actual Atom feeds. Your Atom feeds are valid Atom 1.0, aren't they? :-p Ahem ... cough ... well, yes, actually. Give or take a few non-UTF8 characters that keep creeping in. For the Atom feeds, I seem to have got around the author requirement by using the feed owner as the author of the whole feed. I guess I just have to use that solution and decide where I want to put the author on my pages. For aesthetic reasons, I'd rather not have the author shown on those pages but I think it's counter to the spirit of microformats to write the author block and then hide it using CSS (rendering it machine-readable but human-invisible) so I may just have to bite that particular bullet in the name of compliance. With regard to my other questions, it appears to me that there is a slight disconnect in the mapping between Atom and hAtom, i.e. 1. Atom's atomEntry has atomSource, but hAtom's hentry doesn't appear to have a corresponding 'entry-source' or equivalent. 2. The schema description at http://microformats.org/wiki/hatom#Entry_Content states that 'entry-content' is 'required', but a little later on it merely says that an Entry SHOULD have Entry Content. The Atom spec itself seems to be silent on whether 'atomContent' is required or desirable. There may be other discontinuities, but these are the ones that I've noticed so far. Angus -- Home: http://www.raingod.com/angus/ Blog: http://www.disoriented.net/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
Angus McIntyre wrote: What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. I was under the impression that most of these sorts of requirements are carried over from Atom itself, not things that hAtom invented. For example, the requirements on author as specified in RFC 4287: atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Thus, I suggest you use whatever solution you came up with for generating the actual Atom feeds. Your Atom feeds are valid Atom 1.0, aren't they? :-p Ahem ... cough ... well, yes, actually. Give or take a few non-UTF8 characters that keep creeping in. For the Atom feeds, I seem to have got around the author requirement by using the feed owner as the author of the whole feed. I guess I just have to use that solution and decide where I want to put the author on my pages. For aesthetic reasons, I'd rather not have the author shown on those pages but I think it's counter to the spirit of microformats to write the author block and then hide it using CSS (rendering it machine-readable but human-invisible) so I may just have to bite that particular bullet in the name of compliance. With regard to my other questions, it appears to me that there is a slight disconnect in the mapping between Atom and hAtom, i.e. 1. Atom's atomEntry has atomSource, but hAtom's hentry doesn't appear to have a corresponding 'entry-source' or equivalent. I think you're presenting the first use case for this in hAtom. 2. The schema description at http://microformats.org/wiki/hatom#Entry_Content states that 'entry-content' is 'required', but a little later on it merely says that "an Entry SHOULD have Entry Content". The Atom spec itself seems to be silent on whether 'atomContent' is required or desirable. For Atom, "content" is intended to be used for full content (the entire article, blog post, whatever) while "summary" is intended to be used for "a short summary, abstract, or excerpt of an entry". The idea being that feed providers can be very explicit about what they're providing, and feed consumers can know what kind of thing they're dealing with. It's quite reasonable to have a feed of just summaries if that's what you want to publish (IMHO). -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
Angus McIntyre wrote: These lists of articles - which are essentially 'feeds' - seem like an obvious match for hAtom, so I've tried to make the library produce hAtom. However, there are some problems. First, hAtom demands an author - either at the entry level, or at the feed level - and in these two use cases, there's no obvious author. In the case of the Inca Trail collection, the articles linked to sometimes have authors and sometimes don't. I could put myself as the 'author' of the collection as a whole, but I'm not sure that makes strict sense. I would suggest going with your latter option, even though it's a little ugly. At that point, we're really constrained by the Atom spec and in some technical sense you (or some contact at your organization) is the author of the feed even though you're not the person creating the content of the individual entries. Second, hAtom demands 'entry-content' and makes 'entry-summary' optional. In the first example, there's neither content nor summary (because that's how the client wants it). In the second, the text is really more in the nature of a summary than content, but content is the required item. Atom demands entry:content, hAtom assumes it's the empty string [1] if you don't add it. Finally, the articles all have a 'source' (i.e. the publication where they appeared), but I'm unclear on how to represent that in hAtom. It's always OK to add new things semantic elements, though obviously others won't know what they are -- until they're added to the hAtom spec: - looking through the Atom spec (especially here [2]) for something you can use (via?) and bring it back to the group for discussion - raise an issue in hatom-issues [3] for what's missing and what you [update] I've just looked at what you've done. It's OK as-is [4,5]. What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. But at the same time, it looks as if hAtom fits better than anything else. Should I a. Force my listings into the hAtom mold, by calling the summaries 'content' (and putting in an empty content block in the first case), and adding an author somehow, or b. Avoid using hAtom at all, on the grounds that if I can't meet the requirements, I shouldn't deceive innocent robots by promising them hAtom and not delivering? a. is not an issue -- call your summaries entry-summary and entry-content will default to the empty string Beyond that, I think you're OK except for the author ugliness. I just ran it through the AUMFP and it looks like it's going in the right direction. Regards, etc... David [1] http://microformats.org/wiki/hatom#Entry_Content [2] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rel_attribute [3] http://microformats.org/wiki/hatom-issues#hAtom_0.2 [4] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 [5] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
Couple of minor notes below... David Janes -- BlogMatrix wrote: Angus McIntyre wrote: These lists of articles - which are essentially 'feeds' - seem like an obvious match for hAtom, so I've tried to make the library produce hAtom. However, there are some problems. First, hAtom demands an author - either at the entry level, or at the feed level - and in these two use cases, there's no obvious author. In the case of the Inca Trail collection, the articles linked to sometimes have authors and sometimes don't. I could put myself as the 'author' of the collection as a whole, but I'm not sure that makes strict sense. I would suggest going with your latter option, even though it's a little ugly. At that point, we're really constrained by the Atom spec and in some technical sense you (or some contact at your organization) is the author of the feed even though you're not the person creating the content of the individual entries. Note: The Atom spec provides the atom:source element to handle this. If an extension to hAtom is needed, that's probably the place to look. Second, hAtom demands 'entry-content' and makes 'entry-summary' optional. In the first example, there's neither content nor summary (because that's how the client wants it). In the second, the text is really more in the nature of a summary than content, but content is the required item. Atom demands entry:content, hAtom assumes it's the empty string [1] if you don't add it. Actually, Atom doesn't require entry content, just advises that one of summary or content should be present: Experience teaches that feeds that contain textual content are in general more useful than those that do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry element contain a non-empty atom:title http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.title element, a non-empty atom:content http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content element when that element is present, and a non-empty atom:summary http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary element when the entry contains no atom:content http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content element. However, the absence of atom:summary http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary is not an error, and Atom Processors MUST NOT fail to function correctly as a consequence of such an absence. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
I have seen the issue of author appear more than once in regards to hAtom, so maybe it is time to refactor. hResume has brainstormed away to call back to an object via reference, X2V supports this for vCards and vEvents, so the hAtom XSLT can steal that code if they want. Basically, the idea is that you declare your author at the top of the page or at the first post etc... and you add an ID=foo-bar-author Then inside later posts you simply add: object data=#foo-bar-author/ and this basically is telling the system to include the data inside #foo-bar-author inside the post. http://microformats.org/wiki/resume-brainstorming#hCard_reference_via_object This may or may not be something hAtom wants to look into. -brian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What to do when a microformat doesn't quite fit?
While we're rolling here, can I timidly take offense with the address requirement for author optimization? On that blog post from http://fuzzycontent.com (see nearby thread), I concocted an example which quickly turned out to be invalid, because of this issue. See, I wanted to create an embedded feed, which lists current blog project participants. This is an hAtom feed, embedded in a post, which is part of a blog owned by multiple folk (kind of like microformats.org blog). Address author optimization isn't the right thing, because the hCard only indicates who authors the embedded feed, not the blog or page. Am I out of luck on this example? :DG On 3/21/06, brian suda [EMAIL PROTECTED] wrote: I have seen the issue of author appear more than once in regards to hAtom, so maybe it is time to refactor. hResume has brainstormed away to call back to an object via reference, X2V supports this for vCards and vEvents, so the hAtom XSLT can steal that code if they want. Basically, the idea is that you declare your author at the top of the page or at the first post etc... and you add an ID=foo-bar-author Then inside later posts you simply add: object data=#foo-bar-author/ and this basically is telling the system to include the data inside #foo-bar-author inside the post. http://microformats.org/wiki/resume-brainstorming#hCard_reference_via_object This may or may not be something hAtom wants to look into. -brian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
