Microformats Wiki - User contributions [en]

microformats2-parsing-brainstorming

2016-07-13T14:34:44Z

VoxPelli: /* Parse language information */ Adding link to github issue

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)
* 2016-07-13: Update: created [https://github.com/microformats/microformats2-parsing/issues/3 GitHub issue] for this brainstorm [[User:VoxPelli|VoxPelli]] 14:34, 13 July 2016 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23
** Closed 2015-09-08 because the library has changed and parsing is now handled by microformat-shiv. New issue opened there: https://github.com/glennjones/microformat-shiv/issues/22
* Issue around implementation in php-mf2 added 2016-05-07 https://github.com/indieweb/php-mf2/issues/96

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Language inheritance ===

If the "lang" attribute is not specified for a particular element, it is inherited from the nearest parent (or from the HTTP Content-Language header)

HTML5: https://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes<br>
HTML4: https://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2

Proposal: Determine and include the inherited "lang" value on *every* microformat object that directly specifies a lang or that has an ancestor that does, e.g. if <html lang="en">, then every object in the output will have "lang": "en".

=== Pronouns in different languages ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon me if I butcher Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-x-pronoun to wrap a set of pronouns

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* [[User:Kylewm|Kylewm]] Including the "lang" attribute in h- and e- properties makes a ton of sense to me.
* [[User:Kylewm|Kylewm]] I like the idea of introducing an h-x-pronoun container that can define all the different pronoun forms for a particular language
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2016-05-07T20:12:53Z

VoxPelli: /* Parse language information */ Added link to php-mf2 issue

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23
** Closed 2015-09-08 because the library has changed and parsing is now handled by microformat-shiv. New issue opened there: https://github.com/glennjones/microformat-shiv/issues/22
* Issue around implementation in php-mf2 added 2016-05-07 https://github.com/indieweb/php-mf2/issues/96

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Language inheritance ===

If the "lang" attribute is not specified for a particular element, it is inherited from the nearest parent (or from the HTTP Content-Language header)

HTML5: https://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes<br>
HTML4: https://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2

Proposal: Determine and include the inherited "lang" value on *every* microformat object that directly specifies a lang or that has an ancestor that does, e.g. if <html lang="en">, then every object in the output will have "lang": "en".

=== Pronouns in different languages ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon me if I butcher Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-x-pronoun to wrap a set of pronouns

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* [[User:Kylewm|Kylewm]] Including the "lang" attribute in h- and e- properties makes a ton of sense to me.
* [[User:Kylewm|Kylewm]] I like the idea of introducing an h-x-pronoun container that can define all the different pronoun forms for a particular language
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2015-07-29T09:03:32Z

VoxPelli: Use correct country code in example

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==

Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<code><pre>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</pre></code>

Would be parsed into something like:

<code><pre>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</pre></code>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2015-07-23T18:37:00Z

VoxPelli: add link to experimental microformat-node implementation of language parsing

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==

Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<code><pre>
<div class="h-entry" lang="se">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</pre></code>

Would be parsed into something like:

<code><pre>
{
"type": ["h-entry"],
"lang": "se",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</pre></code>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2015-07-23T18:10:35Z

VoxPelli: based on feedback, added some html to the e-* properties of the language example

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==

Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<code><pre>
<div class="h-entry" lang="se">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</pre></code>

Would be parsed into something like:

<code><pre>
{
"type": ["h-entry"],
"lang": "se",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</pre></code>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2015-07-23T18:09:17Z

VoxPelli: change language example to include actual real swedish and english

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==

Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<code><pre>
<div class="h-entry" lang="se">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an english summary</div>
<div class="e-content">Och svensk huvudtext</div>
</div>
</pre></code>

Would be parsed into something like:

<code><pre>
{
"type": ["h-entry"],
"lang": "se",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an english summary",
"value": "With an english summary"
},
{
"html": "Och svensk huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</pre></code>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

microformats2-parsing-brainstorming

2015-07-23T18:04:56Z

VoxPelli: add brainstorm about parsing language of content

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse language information ==

Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<code><pre>
<div class="h-entry" lang="se">
<h1 class="p-name">A title</h1>
<div class="e-content" lang="en">Abc123</div>
<div class="e-content">Xyz789</div>
</div>
</pre></code>

Would be parsed into something like:

<code><pre>
{
"type": ["h-entry"],
"lang": "se",
"properties": {
"name": ["A title"],
"content": [
{
"lang": "en",
"html": "Abc123",
"value": "Abc123"
},
{
"html": "Xyz789",
"value": "Xyz789"
}
]
}
}
</pre></code>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

hatom-examples-in-wild

2011-12-15T09:36:56Z

VoxPelli: Added Flattr.com as an example

<entry-title>hAtom Examples in the Wild</entry-title>

<div style="height:7.5em;text-align:center;font-weight:bold;font-size:larger">
<span style="padding:3em 0;float:left;width:33%">[[hatom-examples-in-wild#examples_by_category|Want hAtom]]</span><span style="padding:3em 0;float:left;width:33%">[[hatom-examples-in-wild#new_and_uncategorized_examples|Have hAtom]]</span>
</div>

This page is an '''informative''' section of the [[hatom|hAtom draft specification]].

The following sites have published [[hAtom|hAtom]], and thus are a great place to start for anyone looking for examples "in the wild" for inspiration, or to try parsing and indexing.

== new and uncategorized examples ==
'''Have hAtom?''' If you have a site with hAtom, add it to the top of this list. Include at least one URL to a page that includes actual [[hatom|hAtom]] markup. Examples without direct links to pages with hAtom markup will be removed. Check back after a few days, to see if anyone has found any problems with the examples supplied. Note that examples may be categorized and moved to the grouped section below.

You may want to use these buttons on your pages with hAtom. See [[buttons#hAtom]] for any recent additions.
http://www.davidjanes.com/images/mf_hatom.png http://www.boogdesign.com/images/buttons/microformat_hatom.png


* [https://flattr.com/ flattr.com] uses hAtom for the activity streams on its [https://flattr.com/profile/pthulin profiles]. Uses experimental [http://activitystrea.ms/ Activity Streams] classes in it.
* [http://www.gulfdine.com/Restaurant.aspx?Name=Aalishan+-+Al+Muntazah&Restaurant=6497 gulfdine.com] uses hAtom, hReviews for contact information, restaurant information (company address, etc.) and admin reviews.
* [http://brannfan.com/ brannfan.com] uses hAtom for the news entries on its home page and single entry pages.
* [http://www.chipwreck.de/blog/posts/ chipwreck.de] uses hAtom for the (wordpress) blog entries.
* [http://www.zybez.net/ Zybez] uses hAtom for the news entries on its home page.
* The [http://greenvoice.com Greenvoice] Blog, as well as all of the individual campaign blogs on the site ([http://greenvoice.com/campaigns/303-saving-scottish-seals/blogs/595/posts example]), have their posts marked up with hAtom.
* [http://huffduffer.com/ Huffduffer] uses hAtom for the [http://huffduffer.com/new newest] and the most [http://huffduffer.com/popular popular] additions as well as on every user profile and on tag places.
* [http://fairvote.ca/en/WaterlooRegion Waterloo Region Chapter Fair Vote Canada] hAtom enabled until the site enables RSS/Atom in Drupal. Self-referentially linked with Luke Arno's [http://www.lukearno.com/projects/hatom2atom/ hatom2atom service].
* [http://www.aduk.org/ ADUK] use hAtom to mark up news on their home page.
* [http://thetyee.ca/Blogs/TheHook/ The Hook] a Canadian political blog, uses hAtom for blog posts and list of blog posts, however also offers a feedburner RSS feed.
* [http://www.plaintxt.org/experiments/blog-summary/ Blog Summary] is a [[wordpress|WordPress]] plugin from plaintxt.org that generates a semantic list of recent entries in hAtom. By [[implementors#Scott_Allan_Wallick|Scott Allan Wallick]].
* [http://www.yigg.de YiGG (a german social-news community)] Marks up all there Pages with stories using hAtom.
* [http://www.dancefederation.co.uk Dance Federation Salsa Dancing & Jive Dancing Lessons and Events ] Directory for classes, lessons and events users hatom for its news page and generating rss.
* [http://blog.kakkoi.net/ Kakkoi] - combine hAtom (i.e., xFolk RC1, hreview, hAtom) for blog posts and comments.
* [http://www.vibereview.com/ VibeReview] uses hAtom for sex toy reviews and articles (no nudity, but still maybe NSFW). Two feeds can be found on the homepage.
* [http://www.linuxinfusion.com/ Linux Infusion] uses hAtom for blog posts and comments.
* Joseph Bergantine has used hAtom to mark up [http://bergantinedesign.us/blog/my-microwave-has-a-button-that-says-record blog posts], [http://bergantinedesign.us/blog/ article lists], and [http://bergantinedesign.us/blog/doneish#comment000068 comments]
* [http://microrevie.ws/ MicroReviews] marks up each review with [[hAtom]] so that every page can be a feed. See [http://microrevie.ws/ the home page] or [http://microrevie.ws/????? 5-Star Reviews]
* LocalHero (localhero dot biz) A local search which returns it search results in hatom (as well as other microformats).
* [http://blog.livedoor.jp/forestk/ forestk's blog] uses hAtom (note it is Japanese!)
* [http://www.niallkennedy.com/blog/ Niall Kennedy's Weblog] features hAtom on every page. includes comments.
* [http://weborganics.co.uk/ WebOrganics] - Has hAtom feeds on every page.
* [http://journal.redflavor.com/ Reprise] - A [http://redflavor.com/reprise.rb minimal blog] application which uses hAtom out of the box.
* [http://www.bbc.co.uk/worldservice/bangladeshboat BBC World Service Bangladesh River Journey] a social network mashup, with hAtom entries & other microformats. See [http://dharmafly.com/blog/bangladeshboat Dharmafly blog discussion].
* [http://www.people.com/people/news/ People Magazine] uses hAtom to markup the latest news stories.
* [http://www.tamundo.de/ Tamundo] Online auction platform that uses hAtom
* [http://www.bo.ingv.it/italiano/News.html Istituto Nazionale Geofisica e Vulcanologia, Bologna] implemented hAtom entries with embedded rel-tags for categories in its news-page (custom template for [http://www.modxcms.com MODx CMS]).
* [http://v1.itvp.pl/blog/przebojowanoc/i.tvp/idb/24/ ITVP] uses hAtom for entries. See [http://twitter.com/Wojtek/statuses/299700082 Wojtek's announcement 2007-09-28].
* [http://shiftingpixel.com Shifting Pixel] uses hAtom for blog posts and comments.
* [http://lazylibrary.com LazyLibrary] uses hAtom on book results pages.
* [http://findsubstance.com Find Substance Blog] uses hAtom for blog posts.
* [http://www.blogger.com Blogger]
** [http://groups.google.com/group/bloggerDev/browse_thread/thread/69344c5cc35b472e Announcement] on Blogger Dev that all new blogs will have hAtom classes
* AOL
**[http://news.aol.com AOL News], AOL News has implemented hAtom into their center column. This display will be used on other AOL channels as well
**[http://sports.aol.com AOL Sports], AOL Sports is the second AOL channel to use the hAtom display for its center column data
* [http://www.creation.uk.com Creation design & marketing] uses hAtom for a lot of the content as well as [http://www.creation.uk.com/news/2007/06/06/easy-money/ comments on articles].
* [http://www.sndbx.org/ The Sandbox Designs Competition] uses hAtom for all content, hCard for participant (the competition designers) and sponsor information, hCalendar for the competition schedule, XFN for links, and rel-license for licensing information. It's all GNU GPL.
* [http://guyleech.net guyleech.net] uses hCard for contact information.
* [http://kpumuk.info/ Dmytro Shteflyuk] uses hAtom for all blog posts.
* [http://blog.no-panic.at Florian Beer] uses hAtom to mark up all the blog posts. There is also a [http://blog.no-panic.at/2006/11/16/hatom-and-wordpress/ tutorial] on how to convert [[wordpress|WordPress]] themes to include hAtom.
* [http://ficlets.com/ Ficlets] uses hAtom on the [http://ficlets.com/stories main stories page] and on [http://ficlets.com/stories/12 individual story pages].
* [http://www.international.unt.edu UNT International] uses hAtom combined with hCard on news/announcement pages (e.g., [http://www.international.unt.edu/quick/news the main news page]) in addition to providing traditional Atom feeds
* [http://www.absalom.net.au Absalom Media] uses hAtom combined with hCard for articles.
* [http://www.joomlamug.com Joomla! Melbourne User Group] uses hAtom combined with hCard for articles.
* [http://www.volume.co.uk Volume] - Main news page is marked up as hAtom 0.1
* [http://yedda.com Yedda] - Yedda support hAtom on exploration of questions where there is also support for Atom and RSS feeds. ([http://yedda.com/questions/recent/ example])
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club's] frequently-updated [http://www.westmidlandbirdclub.com/new.htm What's New] page, [http://www.westmidlandbirdclub.com/ladywalk/latest.htm news from its Ladywalk Reserve] and [http://www.westmidlandbirdclub.com/worcs/grimley/latest.htm news from Grimley Pits] — comments welcome on my talk page [[User:AndyMabbett|Andy Mabbett]]
* [http://pixelsebi.com pixelsebi's repository] uses hAtom 0.1 for blog posts (and hCard, hCalendar, XFN, xFolk and many more) based on manual [[wordpress|WordPress]] template modifications
* [http://www.qmpeople.com/ qmpeople] uses hAtom combined with hCard for [http://www.qmpeople.com/blog/ blog].
* [http://www.geekinthepark.co.uk Geek in the Park] uses hAtom for the comments. -- by [[User:Trovster|trovster]]
* [http://www.csarven.ca Sarven Capadisli] uses hAtom for the articles and comments -- by [[User:Csarven|csarven]]
* [http://www.capital.edu Capital University] uses hAtom 0.1 to mark up the feed of latest posts by student bloggers on its home page.
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site — by [[User:ChrisCasciano|Chris Casciano]]
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and others; GPLd sources are available at [http://zone.spip.org/trac/spip-zone/browser/_squelettes_/sedna SPIP-Zone])
* [http://quotedprintable.com/pages/scribbish Scribbish] is a Typo theme which uses hAtom.
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl's Changelog] is published as hAtom and Atom.
* [http://federali.st/ federali.st]'s webbed Federalist Papers are each marked up in hAtom.
* [http://www.plaintxt.org/themes/sandbox/ Sandbox] is a theme for [[wordpress|WordPress]] that uses hAtom. By [[implementors#Scott_Allan_Wallick|Scott Allan Wallick]].
** The theme is also available to accounts on the [http://wordpress.com/ <username>.wordpress.com] hosting service. The [http://blog.coworking.info Coworking] and [http://barcamp.wordpress.com BarCamp] blogs are examples of custom Sandbox themes.
** Over 40 designs available for the Sandbox at the [http://www.sndbx.org/ Sandbox Designs Competition], which also uses hAtom
* [http://www.whump.com/dropbox/Strangelove.zip Strangelove] is a modification of the default WordPress theme (Kubrick) with hAtom support.
** It points to the hAtom2Atom proxy service as the link for syndication feeds.
* All [http://www.plaintxt.org/themes/ plaintxt.org themes] for [[wordpress|WordPress]] now use hAtom. The themes are also coded for hCard compliance. The themes, by name, are:
** [http://www.plaintxt.org/themes/barthelme/ Barthelme] (two-column, fluid), [http://www.plaintxt.org/themes/blogtxt/ blog.txt] (two- or three-column, elastic), [http://www.plaintxt.org/themes/plaintxtblog/ plaintxtBlog] (three-column, fluid), [http://www.plaintxt.org/themes/simplr/ Simplr] (one column, elastic), [http://www.plaintxt.org/themes/veryplaintxt/ veryplaintxt] (two column, fluid)
** By [[implementors#Scott_Allan_Wallick|Scott Allan Wallick]].
* [http://www.pats.ua.ac.be/courses PATS Courses], the PATS Research Group uses hAtom to mark up the latest course documents for some of their courses
* [http://mix.excite.co.uk Excite MIX], the Ajax Start Page from Excite Europe, uses hAtom 0.1 and hCard in the Feed Viewer to mark up feed entries and authors.
* [http://last.fm Last.FM], a social music sharing platform, uses hAtom markup for [http://blog.last.fm/2007/05/30/rss-your-shoutbox-and-you shoutbox], and recommends using [http://tools.microformatic.com microformatic]'s transcode tool
* [http://vlograzor.com/ Vlog Razor] - Contains multiple hAtom feeds on the same page.



== examples by category ==
<em>This section is a stub.</em>This list is very incomplete - please see the above uncategorized list and add to existing category(ies) or add new categories accordingly!

'''Want hAtom?''' Use examples from the spec to start with, [[validators|validate]] and publish it, or following the [[hatom-authoring|hAtom authoring tips]] to add hAtom markup to your current site. Check out this section for similar examples of types of pages that benefit from hAtom markup.

=== status updates ===
* [http://twitter.com/ Twitter] publishes hAtom for status updates and short notes [http://twitter.com/al3x/statuses/53982402 since 2007-05-07].
* ...

==Examples with some problems==
Entries may be moved here if there's a problem with the way hAtom is used on the page concerned. If the page is yours, and you want to improve it, see the [[hatom-faq|hAtom FAQ]], or raise any queries on [[hatom-issues|hAtom Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.

=== Pre 0.1 hAtom examples===
These pages conform to an older draft standard and need to be updated.

* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)

==See Also==
{{hatom-related-pages}}