Chris Casciano wrote:
A somewhat silly, but practical question on hatom parsing rules and
opaqueness...
Can you nest hatom feeds... and if so will the inner feed be seen as a
unique item or will it be hidden from parsers because its inside of the
outer feed's content element?
You can nest
I have spent some time reviewing the examples and the formats on the
wiki. Here is the list of the implied schemas. These are the common
fields amongst the examples. I then looked at the cross over between
the real-world examples and the formats and have created a straw
proposal from that. At the
Brian, this is quite impressive. I particularly like the use of hCard
in this context (although I think it's critical that we use more
granular n attributes -- there are just too many ways to mark up a
citation).
Going into your unresolved items -- I see URL being pretty darned
important. It's
On 4/29/06, Brian Suda [EMAIL PROTECTED] wrote:
- IsPartOf is another property that has been discussed which is not represented.
Bringing this together with the publication and journal proprties:
Are these relations, or simple properties (strings)?
They need to be the former, and I think
On 4/29/06, Ross Singer [EMAIL PROTECTED] wrote:
Author/Editor/Translator should be a priority. I realize this is more
important in the computer vs. human continuum, but it doesn't seem
/that/ difficult to make it an easy win for both camps.
I agree. Books, for example, can have all three,
On Apr 29, 2006, at 5:32 PM, Benjamin Carlyle wrote:
It is not clear to me at this time that microformats need profiles.
hcard seems to have several profiles:
http://microformats.org/wiki/hcard-profile
http://www.w3.org/2006/03/hcard
hcalendar seems to have none. Has this harmed adoption or
