xmdp-brainstorming
XMDP Brainstorming
Authors
Add your name here if you make significant contributions to this page and wish to take responsibility for them.
Introduction
Tantek Çelik developed XMDP to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the XMDP spec, a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.
This page is for exploring possible additions / extensions to XMDP.
See xmdp-faq and xmdp-issues for questions and issues.
Possible XMDP additions
Linking to the XMDP
There are at least two additional methods under discussion for linking to the XMDP in addition to the current method of using the profile attribute of the head element:
- Using <link rel="profile" href="link to XMDP"/>. This method can be used now and will be formalized in XHTML 2.
- A problem with this method is that it requires access to the head element.
- Using <a rel="profile" href="link to XMDP">powered by microformat xyz</a> in the body of the document.
- As noted by a number of people, this approach has the added benefit of creating a viral marketing opportunity for the microformats used. For instance, developers could add badges saying they are using microformat xyz as suggested by the example.
- Blog authoring environments allow you to insert links at will, so this squarely obviates the need to access the head element.
Ontology addition
There is currently now way to cross-reference two or more XMDPs. This is proposal about how to link two properties and give some meaning between the two.
For my ficticious example i will use 'self' {{{
- <a href="http://www.gmpg.org/xfn/11#me" rev="extends">self</a>
- This is a pointer to me, it extends the ME property of XFN
}}} There are two interesting pieces that have been added, a URL with an anchor to another XMDP profile and a rev attribute. The rev value in this example is 'extends'. These means that the page this is refering too, is extended by the property SELF. So you could make an XMDP that lists all the possible rev attributes, 'extends', 'inverse', 'equivanent', etc. Then you could 'alias' one microformat property to another.
Then the universal XMDP validator/parser/etc can extract data across two or more XMDP profiles. This would create a small ontology, but also make an endless chase across hrefs through those profiles.
This idea still needs some work, but it might be something of interest to this problem, so i'll hang it out there for comment.
Resolving when microformats are actually in use
One solution to this issue is simply to include the <a rel="profile" href="link to XMDP">powered by microformat xyz</a> within the container element for the microformat. The XMDP spec could then specify that when the <a> element is used in this way, it indicates that the microformat is used by the element containing the <a> element.
There are, however, several clear issues with this proposal:
- Not every microformat has a container element. Consider reltag one of the most widely used microformats.
- To some extent, using microformats adds to the cost of writing the document. It's like filling in a form just to write your thoughts. Putting <a> elements with each microformat adds unwanted links on top of that.
Parsing microformats
Editor's note: should this section be moved to a different document on parsing microformats? This is not specifically about XMDP - Tantek
Microformat parsing mechanisms that depend on documents having even minimal xml properties like well-formedness may fail when consuming non-well-formed content. Tidy may be a useful work around. In particular Brian Suda's frequently cited X2V hCard and hCalendar discovery and transformation prototypes use XSLT, and "tidy" any non-well-formed input before processing it.
Most microformats tend to be agnostic about things like exact element type used.
Developers can use tools like XPATH that assume well-formedness on well-formed content (from the web or by using tidy). Mark Pilgrim's example universal feed parser suggests that it may be possible to sanitize user html to an extent that it is suitable for later processing as xml.