accepted-limitations-of-microformats - Revision history

Tantek: noted title should have simply re-used fn to begin with, with more precise scoping/parsing rules. noted caveat for whole document at top.

2008-08-28T23:02:48Z

noted title should have simply re-used fn to begin with, with more precise scoping/parsing rules. noted caveat for whole document at top.

← Older revision		Revision as of 23:02, 28 August 2008
Line 2:		Line 2:

	This document attempts to outline certain accepted limitations of Microformats. These limitations are partly why Microformats are so simple and easy to implement. Simplicity, however, comes with trade-offs and thus you should be aware of the types of problems that Microformats are not intended to solve.		This document attempts to outline certain accepted limitations of Microformats. These limitations are partly why Microformats are so simple and easy to implement. Simplicity, however, comes with trade-offs and thus you should be aware of the types of problems that Microformats are not intended to solve.

			'''Some of the "trade-offs" and issues listed here are not really limitations of microformats, but rather either misunderstandings of how microformats work, of lack of sufficient scoping/parsing rules in specific formats. Regardless, as these are perceived trade-offs and/or issues, the should be addressed with an FAQ or further documentation. [[User:Tantek\|Tantek]]'''

	== Microformat Scoping Issue ==		== Microformat Scoping Issue ==
Line 53:		Line 55:
	"To specify the job title, functional position or function of the object the vCard represents".		"To specify the job title, functional position or function of the object the vCard represents".

	This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would attempt to fix this problem by causing more complex parsing and confusion by making. "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this confusion has to be avoided by defining <i>audio-title</i> and <i>album-title</i>, or <i>htitle</i> or <i>name</i>.		This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would attempt to fix this problem by causing more complex parsing and confusion by making. "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this confusion has to be avoided by defining <i>audio-title</i> and <i>album-title</i>, or <i>htitle</i> or <i>name</i>. This could all have been avoided by simply properly re-using <i>fn</i> (formatted name) as it has been used in [[hCard]], [[hReview]], [[hListing]] and many proposals, and then specify parsing/context rules appropriately.

	Let us assume for a moment that "title" was defined so loosely that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:		Let us assume for a moment that "title" was defined so loosely that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:

Csarven: Added alternatives for title

2008-08-28T02:55:58Z

Added alternatives for title

← Older revision		Revision as of 02:55, 28 August 2008
Line 53:		Line 53:
	"To specify the job title, functional position or function of the object the vCard represents".		"To specify the job title, functional position or function of the object the vCard represents".

	This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would attempt to fix this problem by causing more complex parsing and confusion by making. "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this confusion has to be avoided by defining <i>audio-title</i> and <i>album-title</i>.		This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would attempt to fix this problem by causing more complex parsing and confusion by making. "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this confusion has to be avoided by defining <i>audio-title</i> and <i>album-title</i>, or <i>htitle</i> or <i>name</i>.

	Let us assume for a moment that "title" was defined so loosely that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:		Let us assume for a moment that "title" was defined so loosely that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:

DanBri: /* Microformat Scoping Issue */ added notes re design tradeoffs

2008-03-31T19:47:10Z

Microformat Scoping Issue: added notes re design tradeoffs

← Older revision		Revision as of 19:47, 31 March 2008
Line 35:		Line 35:
	The reason this would happen is because both hCards overlap. Microformats do not have an established mechanism for identifying which properties go with which VCARD. When it parses Janet Seymour, the first telephone number it finds is Robert Tripton's, not Janet Seymour's. Since the parser doesn't know which person 555-555-5555 belongs to, it mistakenly adds it to Janet Seymour's list of phone numbers. This problem happens whenever you have more than one Microformat of the same type that overlap one another.		The reason this would happen is because both hCards overlap. Microformats do not have an established mechanism for identifying which properties go with which VCARD. When it parses Janet Seymour, the first telephone number it finds is Robert Tripton's, not Janet Seymour's. Since the parser doesn't know which person 555-555-5555 belongs to, it mistakenly adds it to Janet Seymour's list of phone numbers. This problem happens whenever you have more than one Microformat of the same type that overlap one another.

	Keep in mind that the Microformat authors are aware of this limitation, and that the limitation is fine for what the Microformats community is attempting to accomplish - provide a simple mechanism for semantic data markup. Simplicity has its benefits and its drawbacks. RDFa allows you to specify which property goes with which VCARD and solves this issue, at the added cost of a ~~large amount~~ of extra ~~syntax~~.		Keep in mind that the Microformat authors are aware of this limitation, and that the limitation is fine for what the Microformats community is attempting to accomplish - provide a simple mechanism for semantic data markup. Simplicity has its benefits and its drawbacks. RDFa allows you to specify which property goes with which VCARD and solves this issue, at the added cost of extra syntax (whose verbosity will vary depending on the task). A more fundamental tradeoff here is around fragility: RDFa allows great precision and for the free mixing of independently developed extensions. However, this is accomplished by requiring markup to obey the abstract syntax rules of RDFa, which may be hard to grasp. In some contexts, this tradeoff will pay off. Microformats, by contrast, create more work for parser writers (who must for example update their code to track new vocabularies, or evolving consensus about cross-microformat interaction patterns); this is justified on the basis that a handful of parser implementations can be used by everyone, and that it is better to have any extra work done by a handful of specialised experts, than by thousands of HTML publishers.

	== Microformat Namespacing Issue ==		== Microformat Namespacing Issue ==

Kevin Marks: /* Microformat Namespacing Issue */

2007-09-12T21:20:54Z

Microformat Namespacing Issue

Kevin Marks: /* Microformat Scoping Issue */

2007-09-12T21:12:04Z

Microformat Scoping Issue

← Older revision		Revision as of 21:12, 12 September 2007
Line 5:		Line 5:
	== Microformat Scoping Issue ==		== Microformat Scoping Issue ==

	A ~~good real-world~~ example of the Microformats Scoping issue is outlined in the following section. Let's take the following text and try to mark it up using the hCard Microformat:		A strangely contrived example of the Microformats Scoping issue is outlined in the following section. Let's take the following text and try to mark it up using the hCard Microformat:

	Janet Seymour and Robert Tripton are available via phone.		Janet Seymour and Robert Tripton are available via phone.
Line 35:		Line 35:
	The reason this would happen is because both hCards overlap. Microformats do not have an established mechanism for identifying which properties go with which VCARD. When it parses Janet Seymour, the first telephone number it finds is Robert Tripton's, not Janet Seymour's. Since the parser doesn't know which person 555-555-5555 belongs to, it mistakenly adds it to Janet Seymour's list of phone numbers. This problem happens whenever you have more than one Microformat of the same type that overlap one another.		The reason this would happen is because both hCards overlap. Microformats do not have an established mechanism for identifying which properties go with which VCARD. When it parses Janet Seymour, the first telephone number it finds is Robert Tripton's, not Janet Seymour's. Since the parser doesn't know which person 555-555-5555 belongs to, it mistakenly adds it to Janet Seymour's list of phone numbers. This problem happens whenever you have more than one Microformat of the same type that overlap one another.

	Keep in mind that the Microformat authors are aware of this limitation, and that the limitation is fine for what the Microformats community is attempting to accomplish - provide a simple mechanism for semantic data markup. Simplicity has its benefits and its drawbacks. RDFa allows you to specify which property goes with which VCARD and solves this issue, at the added cost of a ~~small~~ amount of extra syntax.		Keep in mind that the Microformat authors are aware of this limitation, and that the limitation is fine for what the Microformats community is attempting to accomplish - provide a simple mechanism for semantic data markup. Simplicity has its benefits and its drawbacks. RDFa allows you to specify which property goes with which VCARD and solves this issue, at the added cost of a large amount of extra syntax.

	== Microformat Namespacing Issue ==		== Microformat Namespacing Issue ==

Brian: NOTED that we should avoid theoretical issues

2007-09-12T20:07:30Z

NOTED that we should avoid theoretical issues

← Older revision		Revision as of 20:07, 12 September 2007
Line 38:		Line 38:

	== Microformat Namespacing Issue ==		== Microformat Namespacing Issue ==

			(This should be changed to a REAL issue NOT a theortical one. By simply changing hAudio's TITLE to FN, solves all issues in this example. PLEASE replace, it is miss-leading and un-true in this case, this is why we select good property names from the begining to avoid these issues. If there is a real issue please document it, otherwise there is no need to continue to spread FUD)

	The following is a theoretical example, based on work performed for hAudio, that shows how not having namespaces can be detrimental to scalability. There was a [http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html discussion on the New Microformats mailing list] regarding the re-use of the 'title' property from hCard. Re-use of property names in Microformats is heavily encouraged, but it creates several problems:		The following is a theoretical example, based on work performed for hAudio, that shows how not having namespaces can be detrimental to scalability. There was a [http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html discussion on the New Microformats mailing list] regarding the re-use of the 'title' property from hCard. Re-use of property names in Microformats is heavily encouraged, but it creates several problems:

ManuSporny: Created accepted-limitations-of-microformats page

2007-09-12T16:12:59Z

Created accepted-limitations-of-microformats page

New page

= Introduction =

This document attempts to outline certain accepted limitations of Microformats. These limitations are partly why Microformats are so simple and easy to implement. Simplicity, however, comes with trade-offs and thus you should be aware of the types of problems that Microformats are not intended to solve.

== Microformat Scoping Issue ==

A good real-world example of the Microformats Scoping issue is outlined in the following section. Let's take the following text and try to mark it up using the hCard Microformat:

Janet Seymour and Robert Tripton are available via phone.
Rob is available at his home number: 555-555-5555.
Janet can be reached at her work number: 777-777-7777.

A publisher would want to mark-up Janet and Robert's telephone contact information. Not knowing that Microformats are scope-less, they might take the following approach:

<div class="vcard">
<span class="fn">Janet Seymour</span> and
<div class="vcard">
<span class="fn">Robert Tripton</span> are available via phone.
Rob is available at his home number: <span class="tel">555-555-5555</span>.
</div>
Janet can be reached at her work number: <span class="tel">777-777-7777</span>.
</div>

Unfortunately, the Microformat parser would generate the following two Microformat outputs:

hCard
fn -> Janet Seymour
tel -> 555-555-5555
tel -> 777-777-7777

hCard
fn -> Robert Tripton
tel -> 555-555-5555

The reason this would happen is because both hCards overlap. Microformats do not have an established mechanism for identifying which properties go with which VCARD. When it parses Janet Seymour, the first telephone number it finds is Robert Tripton's, not Janet Seymour's. Since the parser doesn't know which person 555-555-5555 belongs to, it mistakenly adds it to Janet Seymour's list of phone numbers. This problem happens whenever you have more than one Microformat of the same type that overlap one another.

Keep in mind that the Microformat authors are aware of this limitation, and that the limitation is fine for what the Microformats community is attempting to accomplish - provide a simple mechanism for semantic data markup. Simplicity has its benefits and its drawbacks. RDFa allows you to specify which property goes with which VCARD and solves this issue, at the added cost of a small amount of extra syntax.

== Microformat Namespacing Issue ==

The following is a theoretical example, based on work performed for hAudio, that shows how not having namespaces can be detrimental to scalability. There was a [http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html discussion on the New Microformats mailing list] regarding the re-use of the 'title' property from hCard. Re-use of property names in Microformats is heavily encouraged, but it creates several problems:

# If somebody narrowly defines the meaning of a property, re-using that property is difficult if not impossible.
# The more you re-use a property, the more risk there is of property name clashes when Microformats overlap on a web page.

The question of whether or not we should be using <i>title</i> when referring to the title of a song, or the title of an album, was raised several times while discussing hAudio. The [http://www.m-w.com/dictionary/title definition for the word 'title'] in this sense is:

5 a) the distinguishing name of a written, printed, or filmed production
b) a similar distinguishing name of a musical composition or a work of art.

Unfortunately, the hCard authors narrowly defined <i>title</i>. They re-used the VCARD definition. The VCARD specification defines <i>title</i> as:

To specify the job title, functional position or function of the object the vCard represents".

This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would fix this problem as "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this distinction cannot be made.

Let us assume for a moment that "title" was defined in such a way that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:

Freddie Mercury, known for a song called Bohemian Rhapsody, was the lead singer for Queen.

The HTML markup would look like this:

<div class="vcard">
<span class="fn">Freddie Mercury</span>,
known for a song called
<div class="haudio">
<span class="title">Bohemian Rhapsody</span>,
</div>
was the <span class="title">lead singer</span>
for <span class="org">Queen</span>.
</div>

The Microformat parser above would generate the following two outputs:

hCard
fn -> Freddie Mercury
title -> Bohemian Rhapsody
org -> Queen

hAudio
title -> Bohemian Rhapsody

Even though title is the desired word to use, due to the scoping issue explained in the previous section, and because Microformats do not have namespaces, we were forced to use a different property name. hAudio currently uses the property name <i>audio-title</i> and <i>album-title</i> in an effort to avoid namespace and scoping issues. Ironically, the use of the dash character in "audio-title" and "album-title" is a very simple form of namespacing... something that Microformats were attempting to avoid.

This limitation is also well known to the Microformats authors and is currently viewed as an acceptable price to pay for an easy-to-implement markup mechanism for publishers. RDFa has namespacing and thus solves this issue, at the added cost of a small amount of extra syntax.

← Older revision		Revision as of 21:20, 12 September 2007
Line 39:		Line 39:
	== Microformat Namespacing Issue ==		== Microformat Namespacing Issue ==

	(This should be changed to a REAL issue NOT a theortical one. By simply changing hAudio's TITLE to FN, solves all issues in this example. PLEASE replace, it is miss-leading and un-true in this case, this is why we select good property names from the begining to avoid these issues. If there is a real issue please document it, otherwise there is no need to continue to spread FUD)		The following is a theoretical example, based on work performed for hAudio, that shows how making poor choices of element naming can lead to confusion. There was a [http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html discussion on the New Microformats mailing list] regarding the re-use of the 'title' property from hCard. Re-use of property names in Microformats is heavily encouraged, but it needs to be done with care:

	The following is a theoretical example, based on work performed for hAudio, that shows how ~~not having namespaces~~ can ~~be detrimental~~ to ~~scalability~~. There was a [http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html discussion on the New Microformats mailing list] regarding the re-use of the 'title' property from hCard. Re-use of property names in Microformats is heavily encouraged, but it ~~creates several problems~~:

	# If somebody narrowly defines the meaning of a property, re-using that property is difficult if not impossible.		# If somebody narrowly defines the meaning of a property, re-using that property is difficult if not impossible.
	# The more you re-use a property, the more risk there is of ~~property name~~ clashes when Microformats overlap on a web page.		# The more you re-use a property, the more risk there is of interpretation clashes when Microformats overlap on a web page.

	The question of whether or not we should be using <i>title</i> when referring to the title of a song, or the title of an album, was raised several times while discussing hAudio. The [http://www.m-w.com/dictionary/title definition for the word 'title'] in this sense is:		The question of whether or not we should be using <i>title</i> when referring to the title of a song, or the title of an album, was raised several times while discussing hAudio. The [http://www.m-w.com/dictionary/title definition for the word 'title'] in this sense is:
Line 51:		Line 49:
	b) a similar distinguishing name of a musical composition or a work of art.		b) a similar distinguishing name of a musical composition or a work of art.

	~~Unfortunately~~, the hCard authors ~~narrowly~~ defined <i>title</i>. They re-used the VCARD definition. The VCARD specification defines <i>title</i> as:		However, the hCard authors previously defined <i>title</i>. They re-used the VCARD definition. The VCARD specification defines <i>title</i> as:

	To specify the job title, functional position or function of the object the vCard represents".		"To specify the job title, functional position or function of the object the vCard represents".

	This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would fix this problem as "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this ~~distinction cannot~~ be ~~made~~.		This means that any Microformat that desires to use <i>title</i> must use the definition used by VCARD, since that specification was created first and changing it might confuse people who have adopted VCARD. Having a namespace would attempt to fix this problem by causing more complex parsing and confusion by making. "hCard:title" could mean something subtly different from "hAudio:title" - however, since there are no namespaces in Microformats, this confusion has to be avoided by defining <i>audio-title</i> and <i>album-title</i>.

	Let us assume for a moment that "title" was defined ~~in such a way~~ that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:		Let us assume for a moment that "title" was defined so loosely that would have allowed hAudio to re-use the property. There is another problem that goes back to the example given in Appendix A. How do you differentiate between two Microformats that overlap with the same property name? Take this sentence for example:

	Freddie Mercury, known for a song called Bohemian Rhapsody, was the lead singer for Queen.		Freddie Mercury, known for a song called Bohemian Rhapsody, was the lead singer for Queen.
Line 83:		Line 81:
	title -> Bohemian Rhapsody		title -> Bohemian Rhapsody

	Even though title is the desired word to use, due to ~~the scoping issue explained in the previous section~~, ~~and because Microformats do not have namespaces, we were~~ forced to use a different property name. hAudio currently uses the property name <i>audio-title</i> and <i>album-title</i> ~~in an effort~~ to avoid namespace and scoping issues. ~~Ironically, the~~ use of the dash character in "audio-title" and "album-title" is a very simple ~~form~~ of ~~namespacing... something that Microformats were attempting to avoid.~~		Even though title is the desired word to use, due to its ambiguity, hAudio was forced to use a different property name. hAudio currently uses the property name <i>audio-title</i> and <i>album-title</i>to avoid namespace and scoping issues. The use of the dash character in "audio-title" and "album-title" is a very simple way of creating separate names, avoiding the complexity and ambiguity of XML namespaces

	This limitation is also well known to the Microformats authors and is ~~currently viewed as an acceptable~~ price ~~to pay~~ for an easy-to-implement markup mechanism for publishers~~. RDFa has namespacing and thus solves this issue, at the added cost of a small amount of extra syntax~~.		This limitation is also well known to the Microformats authors and is designed to avoid the price of complex namespacing for an easy-to-implement markup mechanism for publishers.