The point is not that the document can or cannot be parsed with a schema. The point is that the schema allows parsers to be generated automatically rather than hand-code them for each microformat and for each programming language.

As for collisions, it’s not that you couldn’t write a parser that knew that an email address inside a vcard was different than an email address inside an hreview, or that hreviews might contain vcards which, in turn, might contain email addresses that should be associated with the latter. The point is that if there is a clear grammar, then one doesn’t have to worry about whether their hand parser will misread a microformat when another, unexpected microformat is nested inside it.

Can you give a specific example of a document that could be parsed automatically with a schema, and couldn’t be parsed automatically without?

So, instead of trying to squeeze in data in an attribute which isn’t meant to hold it (e.g. title) one could do like this:

[span class=”dtstart MMM-dd-yyyy”]Dec 24 2007[/span]

Of course this creates other problems (e.g. how to represent other characters while maintaining valid values for class names). Maybe some more research should be done to see if this works.

But, we follow DRY and do not abuse the title element.

“Gibberish
Code”

Should be:
<dc:subject>Gibberish</dc:subject>
<dc:subject>Code</dc:subject>

Hopefully this will work.

This chunk of code in rss_parse.inc seems to explain the problem.

// if inside an Atom content construct (e.g. content or summary) field treat tags as text
elseif ($this->feed_type == ATOM and $this->incontent )
{
// if tags are inlined, then flatten
$attrs_str = join(’ ‘,
array_map(’map_attrs’,
array_keys($attrs),
array_values($attrs) ) );

$this->append_content( “” );

array_unshift( $this->stack, $el );
}

The PHP code takes the below Atom data:
Gibberish
Code

And turns it in to (output as JSON):
“dc”:{”subject”:”GibberishCode”}

Which I agree is not a good solution, and would go as far as saying that it is just wrong. Flattening the data structure destroys a lot of the stored information (which does not have to happen).

I can see at least one solution off the top of my head, but I do not know the ramifications of the modifications without studying the library a good bit more.

[abbr class=”dtstart” title=”2006-05-01T12:15:03.0Z”]5:15am[/abbr]

title is for accessibility. It helps to have a better understanding of the content. In the microformat use it’s becoming the opposite. In a sense, this would be more logical in terms of accessibility

[abbr class=”dtstart” title=”5:15am”]2006-05-01T12:15:03.0Z[/abbr]

but then it would go against the microformat principles of making it readable.

The second issue is that it doesn’t respect the DRY principle. There is a redundancy of information and then it’s prone to errors when we update it. For example, someone with a wysiwyg tool.

I would rather prefer something like that:

[span class=”dtstart tz-Z time”]5:15am[/span]

And then the rest of javascript needed to make it right in display and processing.

James Snell (also at IBM) has agreed to work on this with me… hopefully we’ll have an IETF draft soon.