xmdp-issues
XMDP issues
These are externally raised issues about XMDP with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek
See related xmdp-faq and xmdp-brainstorming.
Closed Issues
Resolved issues that have no further actions to take. These will likely be moved to a separate page like xmdp-issues-closed.
2005
- 2005-07-?? raised by Bud.
- Just because a profile value mentioned in a microformat's linked XMDP also appears in the document does not mean that that microformat is in use. Such co-occurrences could be purely by chance.
- REJECTED. No this does not make sense. By definition, an XMDP profile defines certain properties and values. Any use of such property or value in the document is thus defined by the definition in the XMDP.
- Just because a profile value mentioned in a microformat's linked XMDP also appears in the document does not mean that that microformat is in use. Such co-occurrences could be purely by chance.
- 2005-07-13T20:01-07:00 raised by Bud.
- Follow-up to above issue: Actually, this is far from clear. Reading this excerpt from the XMDP description: "This specification does not define a set of legal meta data properties. The meaning of a property and the set of legal values for that property should be defined in a reference lexicon called a profile. For example, a profile designed to help search engines index documents might define properties such as "author", "copyright", "keywords", etc." seems not to imply exclusivity for the whole document, only for the part covered by the profile. If we assumed the quoted words implied exclusivity for the whole document, then only defined attribute values could be used for the whole document. The current usage suggests that we mean the profile to only cover the part of the document covered by the microformat. As such, we cannot use occurrence of a value to connote presence of the microformat. Consider this example, xFolk and hCalendar both use a description class attribute value. Presence of that value is therefore indeterminate as to which format is being used, even if we accepted your claim here, which seems dubious.
- REJECETD. Bud, that quote you give is XMDP quoting HTML4, please re-read the XMDP spec more carefullly. This is a non-issue.
- Follow-up to above issue: Actually, this is far from clear. Reading this excerpt from the XMDP description: "This specification does not define a set of legal meta data properties. The meaning of a property and the set of legal values for that property should be defined in a reference lexicon called a profile. For example, a profile designed to help search engines index documents might define properties such as "author", "copyright", "keywords", etc." seems not to imply exclusivity for the whole document, only for the part covered by the profile. If we assumed the quoted words implied exclusivity for the whole document, then only defined attribute values could be used for the whole document. The current usage suggests that we mean the profile to only cover the part of the document covered by the microformat. As such, we cannot use occurrence of a value to connote presence of the microformat. Consider this example, xFolk and hCalendar both use a description class attribute value. Presence of that value is therefore indeterminate as to which format is being used, even if we accepted your claim here, which seems dubious.
Resolved Issues
Issues that are resolved but may have outstanding to-do items. As issues are resolved, they will be moved from the top of the Issues list to the bottom of this section.
2005
- 2005-07-?? raised by Bud(?).
- Currently, the XMDP can only be linked from the profile attribute of the head element. In many instances, authors will not have access to the head element.
- ACCEPTED. There are two additional proposed ways to link to XMDP profiles which are being discussed/explored in xmdp-brainstorming:
<link rel="profile">, as introduced in the XMDP poster submitted to WWW2005.<a rel="profile" href>, as similarly discussed.
- ACCEPTED. There are two additional proposed ways to link to XMDP profiles which are being discussed/explored in xmdp-brainstorming:
- Consider the supporting use cases: Providing explicit profile definitions for microformats embedded in RSS and Atom and other feeds / envelope formats that don't necessarily have a <head> element with a 'profile' attribute or something similar. I.e. : A very practical motivation for this question is the process of embedding xFolk in an RSS 2.0 feed and the ability to indicate the microformat is in use and where information about it can be found.
- ACCEPTED. These are good use cases and will be cited in any development/improvement to XMDP.
- Currently, the XMDP can only be linked from the profile attribute of the head element. In many instances, authors will not have access to the head element.
Issues
Add new issues to the end of this list.
2007
From: Dave Orchard's Blog: Microformats and URI based extensibility
- TO DO: extract issues from that URL and itemize them here.
- 2007-11-07 raised by Tantek
- xmdp-parsing needs to be specified above and beyond the declarative explanation in XMDP.
Feel free to add issues here. Keep issues in this list in summary form. Save lengthy discussion and potential solutions for elaboration below.
Template
Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.
Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.
<div class="hentry">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="published">2011-MM-DD</span>
raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>