misconceptions: Difference between revisions
(broke out additional profile text as a mix of misconception and moved one to criticism.) |
(add articles about misconceptions section, cite csarven article and list topics it coveres) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 13: | Line 13: | ||
Second, [[compound microformats]] (e.g. [[hCard]], [[hCalendar]], [[hReview]]) use a fairly uniquely chosen string for the "root element" (e.g. <code>vcard</code>, <code>vcalendar</code>, <code>vevent</code>, <code>hreview</code>) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name. | Second, [[compound microformats]] (e.g. [[hCard]], [[hCalendar]], [[hReview]]) use a fairly uniquely chosen string for the "root element" (e.g. <code>vcard</code>, <code>vcalendar</code>, <code>vevent</code>, <code>hreview</code>) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name. | ||
=== context awareness means microformats use namespaces === | |||
misconception: If Microformats ARE context aware, then there is the concept of namespaces in Microformats. | |||
This is flawed for the same reason that just because all squares are rectangles, it doesn't mean that all rectangles are squares. | |||
Context is not the same as [[namespaces]]. Namespaces provide one form of context, but not all contexts are namespaces. In the case of compound microformats, the context that is used is hierarchical containment, not namespaces. | |||
=== microformats use non URI based extensibility === | === microformats use non URI based extensibility === | ||
| Line 28: | Line 36: | ||
The [http://gmpg.org/xmdp/description XMDP spec] and the [http://www.w3.org/2003/g/data-view GRDDL] spec show how to make a profile, and how generic data clients to follow, to either ground the data into RDF, or use the data directly as microformats with terms defined by their XMDP+ID URIs. This will maximize re-use of the data, in combination wit other data. There is a growing class of [http://esw.w3.org/topic/GrddlImplementations grddl-aware systems] which will use GRDDL-enabled microformat data without any alteration. | The [http://gmpg.org/xmdp/description XMDP spec] and the [http://www.w3.org/2003/g/data-view GRDDL] spec show how to make a profile, and how generic data clients to follow, to either ground the data into RDF, or use the data directly as microformats with terms defined by their XMDP+ID URIs. This will maximize re-use of the data, in combination wit other data. There is a growing class of [http://esw.w3.org/topic/GrddlImplementations grddl-aware systems] which will use GRDDL-enabled microformat data without any alteration. | ||
* A response at http://www.pacificspirit.com/blog/2007/09/28/microformats_and_uri_based_extensibility | |||
=== microformats tools will erroneously pick up data === | === microformats tools will erroneously pick up data === | ||
| Line 44: | Line 54: | ||
''microformats do not scale when domain-specific, or culture-specific, or company-specific microformats are added.'' | ''microformats do not scale when domain-specific, or culture-specific, or company-specific microformats are added.'' | ||
Microformats are not trying to solve all problems, in fact, that is a specific non-goal. See the microformats [[principles]]. In practice, one does not have to solve all problems, nor even make it possible to solve all problems. | Microformats are not trying to solve all problems, in fact, that is a specific non-goal. See the [[microformats]] [[principles]]. In practice, one does not have to solve all problems, nor even make it possible to solve all problems. | ||
Microformats are trying to represent the 80/20 of semantics on the public web, and thus solve most problems that will actually help most people on the public web. | Microformats are trying to represent the 80/20 of semantics on the public web, and thus solve most problems that will actually help most people on the public web. | ||
| Line 50: | Line 60: | ||
For domain-specific, or culture-specific, or company-specific semantics, those authors should simply make use of the best [[POSH]] that they can, with their own profiles and profile URLs, and if their domain-specific, or culture-specific, or company-specific semantics become widely adopted on the web, then that may provide a good case for taking their [[POSH]] through the microformats [[process]] to develop a new microformat. | For domain-specific, or culture-specific, or company-specific semantics, those authors should simply make use of the best [[POSH]] that they can, with their own profiles and profile URLs, and if their domain-specific, or culture-specific, or company-specific semantics become widely adopted on the web, then that may provide a good case for taking their [[POSH]] through the microformats [[process]] to develop a new microformat. | ||
=== current behaviors and usage patterns in general === | |||
More there once folks have made the overgeneralization that microformats are/adapted to "current behaviors and usage patterns" in general, and then use that overgeneralization to justify: | |||
* current behaviors of user agents | |||
* current browser usage patterns | |||
* other generalizations | |||
as design centers for microformats. Unfortunately this is incorrect and dilutes the focus of microformats. | |||
A quote taken out of context such as the following has been used to justify the overgeneralization: From the [http://microformats.org/about/ microformats about page]: <blockquote>microformats are: [...] adapted to current behaviors and usage patterns</blockquote> | |||
This is precisely demonstrates the "taking out of context" logical flaw. If you read the entire quote: <blockquote><p>Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).</p></blockquote> | |||
You can see that the "current behaviors and usage patterns" specifically applies to *markup*, *content*, and *publishing* "(e.g. XHTML, blogging)". | |||
Microformats adapt to current ''content publishing behaviors'' and ''markup usage'' patterns. Not current behaviors and usage patterns in general. More on this is clear from the [[principles]] and the [[process]]. | |||
This is actually a ''very'' important distinction, as focusing on the ''content publishing'' side of things is one the ways microformats greatly succeeds. By focusing on making things easier for ''publishers'' (rather than ''developers'', ''parsers'', ''browser vendors'', etc.), microformats lowers barriers for the most people. Specifically, lowering barriers for ''publishers'' to publish semantic content (from [[POSH]] on up) helps solve the chicken-egg problem that such content often suffers from, as publishers will often do something if it at least has some benefit, ''if'' it is very easy to do so. | |||
=== schema would improve interoperability of microformats === | |||
Once in a while someone will propose a more formal schema to define a microformat (often a typed schema), with the assertion that a schema would improve interoperability of microformats. | |||
There are several problems with this assertion that are best described with questions: | |||
What is the real world interoperability problem that you are trying to solve? | |||
Do you have test cases that have been demonstrated to fail in specific implementations? | |||
Do you have analysis that demonstrates that such problems stem from a lack of an explicit typed schema? | |||
Lacking that, it is not logical to conclude that a schema would help improve interoperability. | |||
=== schema incompleteness problem === | |||
Somewhat related to the schema interoperability misconception noted above, advocates of schemas in general often make the implicit assumption that if they have a schema for something, it somehow means they've fully expressed that something, potentially in a way that can be "automatically" parsed, etc. | |||
In practice, explicit schemas do not represent all (often not even most) of the semantics of a specific format. For example, the HTML4 DTDs contain a mere fraction of the constraints and semantics expressed by the HTML4 specification. A validator that only checks the rules expressed in the HTML DTD will fail to check numerous assertions and requirements made in the specification itself. This is the schema incompleteness problem. In short, having a set of rules from a framework (such as those expressed by a schema like a DTD) is not only in practice insufficient, but serves to give a false sense of completeness of description. | |||
Thus with microformats we eschew trying to solve the general schema problem (others are trying much harder for much longer on that problem - e.g. XML Schema etc., and failing in practice - i.e. usage on the Web) for simple dictionaries instead. | |||
There has been some value demonstrated in some scenarios (e.g. reading microformats into an RDF store, either directly or thru a GRDDL transform) to at least disambiguate the use of vocabulary, and back the terms used with URLs. Thus we have [[XMDP]] (XHTML Meta Data Profiles) which is sufficient to define terms and provide a URL for each. | |||
== articles == | |||
Article about microformats misconceptions: | |||
<div class="h-cite"> | |||
* <time class="dt-published">2008-05-20</time> <span class="p-author h-card">Sarven Capadisli</span> <cite><span class="p-name">Microformats: Moving along with the evolution of the Web</span> <<span class="u-url">http://csarven.ca/microformats-misconceptions</span>></cite> touches on: | |||
** assumption of '''<span class="p-category">complexity</span>''' | |||
** prefering '''<span class="p-category">natural language processing</span>''' | |||
** assumption of '''<span class="p-category">language</span>''' | |||
** '''<span class="p-category">reusing names</span>''' | |||
** assumption of specific '''<span class="p-category">markup</span> or tags''' | |||
** assumption of '''<span class="p-category">separate files</span>''' being better | |||
** assumption of need to '''<span class="p-category">solve all our problems</span>''' | |||
** '''<span class="p-category">verbosity</span>''' | |||
** '''<span class="p-category">abuse of data</span>''' | |||
** '''<span class="p-category">internationalization</span>''' | |||
** '''<span class="p-category">accessibility</span>''' | |||
</div> | |||
== see also == | == see also == | ||
* [[faq]] | * [[faq]] | ||
* [[xmdp]] | * [[xmdp]] | ||
* [[namespaces-considered-harmful]] | |||
* [[criticism]] | * [[criticism]] | ||
Latest revision as of 19:48, 3 September 2015
misconceptions about microformats
Some misconceptions either appear often enough, or may have been held by people that are experts in the fields of markup, web standards etc., and thus it is useful to document and debunk them.
misconceptions
microformats use unscoped class names
misconception: Microformats definitions use unqualified/scoped class attribute strings as semantic tags.
This is incorrect on two counts.
First, microformats make use of profile URLs to define class name semantics. Thus it is entirely possible (though both unlikely, and undesirable) for someone to redefine class names with their own definitions in their own profile URL.
Second, compound microformats (e.g. hCard, hCalendar, hReview) use a fairly uniquely chosen string for the "root element" (e.g. vcard, vcalendar, vevent, hreview) and then generic terms only inside that root element. Thus use of any generic terms are scoped (some might even say "namespaced") within the fairly uniquely chosen "root element" class name.
context awareness means microformats use namespaces
misconception: If Microformats ARE context aware, then there is the concept of namespaces in Microformats.
This is flawed for the same reason that just because all squares are rectangles, it doesn't mean that all rectangles are squares.
Context is not the same as namespaces. Namespaces provide one form of context, but not all contexts are namespaces. In the case of compound microformats, the context that is used is hierarchical containment, not namespaces.
microformats use non URI based extensibility
misconception: Microformats use non-URI based extensibility.
Microformats make use of the profile attribute, in the <head> element to reference one or more profiles (this is all per HTML4 spec) to an XMDP profile document (XMDP is derived from the "hints" in HTML4 as to what a profile document "could" be), to define specific rel (e.g. XFN 1.1 profile and class (e.g. hCard profile) values.
Thus microformats are built upon a form of URI based extensibility. Tantek did this by design for XFN, his first experiment into formally extending HTML, and before he even coined the word "microformat" (XMDP & XFN were developed in 2003, "microformats" were first proposed in 2004).
What we have found is that, just like HTML was often used in the wild without explicit DOCTYPE URIs (and tools e.g. browsers supported it), microformats are often used in the wild without explicit profile URLs (and tools e.g. browser plugins support it).
Missing a DOCTYPE does little or no damage today, as (modulo tag soup issues) the DOCTYPE is a link in the chain of reasoning about what the document means. It's been asserted that the HTML profile for microformats is however a crucial link, which perhaps similar to the assertion made by the SGML community back when HTML was introduced that the DOCTYPE for HTML is a crucial link. The parallels are nearly identical.
However, despite how browsers make good sense of HTML sans DOCTYPEs today, witness how nearly no general user-centric user agents have been built to make sense of the babel of XML sans DOCTYPEs that is being published. Given the failure of XML use in practice to make use of URI based extensibility, and the subsequent failure for there to be any widespread user-centric user agents (e.g. browsers) that make use of that content, the lesson to learn here is that it is therefore important to use the profile attribute for microformats, and encourage its use.
The XMDP spec and the GRDDL spec show how to make a profile, and how generic data clients to follow, to either ground the data into RDF, or use the data directly as microformats with terms defined by their XMDP+ID URIs. This will maximize re-use of the data, in combination wit other data. There is a growing class of grddl-aware systems which will use GRDDL-enabled microformat data without any alteration.
microformats tools will erroneously pick up data
One danger of omitting profiles is that, because tools such as browser plugins support microformats without checking for a profile, then those tools will erroneously pick up data from pages which use classes for a completely unrelated purpose. This attributes to the author information which they never meant to give. '
This scenario is highly unlikely and has yet to occur in the real web due to the fairly uniquely chosen root class names for microformats which tools look for before they look for the more generically named classes inside microformats.
no generic data gathering device can be built
The other danger of omitting profiles is that no generic data-gathering device can be built. The web ceases to be self-describing, in that there then would be no one common algorithm for deriving the data from a given page.'
It is difficult to disprove a negative statement as the first sentence, and, this is strictly a theoretical problem, as no generic data-gathering device has been built.
Similarly, the web is not self-describing currently with widespread use of HTML, tag soup, invalid XML, etc. thus saying it ceases to be self-describing is misleading, because there is no "ceasing". If anything, by increasing the semantics expressed on the existing web, the use of microformats increases how much each page self-describes its own semantics.
do not scale when domain specific microformats are added
microformats do not scale when domain-specific, or culture-specific, or company-specific microformats are added.
Microformats are not trying to solve all problems, in fact, that is a specific non-goal. See the microformats principles. In practice, one does not have to solve all problems, nor even make it possible to solve all problems.
Microformats are trying to represent the 80/20 of semantics on the public web, and thus solve most problems that will actually help most people on the public web.
For domain-specific, or culture-specific, or company-specific semantics, those authors should simply make use of the best POSH that they can, with their own profiles and profile URLs, and if their domain-specific, or culture-specific, or company-specific semantics become widely adopted on the web, then that may provide a good case for taking their POSH through the microformats process to develop a new microformat.
current behaviors and usage patterns in general
More there once folks have made the overgeneralization that microformats are/adapted to "current behaviors and usage patterns" in general, and then use that overgeneralization to justify:
- current behaviors of user agents
- current browser usage patterns
- other generalizations
as design centers for microformats. Unfortunately this is incorrect and dilutes the focus of microformats.
A quote taken out of context such as the following has been used to justify the overgeneralization: From the microformats about page:
microformats are: [...] adapted to current behaviors and usage patterns
This is precisely demonstrates the "taking out of context" logical flaw. If you read the entire quote:
Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).
You can see that the "current behaviors and usage patterns" specifically applies to *markup*, *content*, and *publishing* "(e.g. XHTML, blogging)".
Microformats adapt to current content publishing behaviors and markup usage patterns. Not current behaviors and usage patterns in general. More on this is clear from the principles and the process.
This is actually a very important distinction, as focusing on the content publishing side of things is one the ways microformats greatly succeeds. By focusing on making things easier for publishers (rather than developers, parsers, browser vendors, etc.), microformats lowers barriers for the most people. Specifically, lowering barriers for publishers to publish semantic content (from POSH on up) helps solve the chicken-egg problem that such content often suffers from, as publishers will often do something if it at least has some benefit, if it is very easy to do so.
schema would improve interoperability of microformats
Once in a while someone will propose a more formal schema to define a microformat (often a typed schema), with the assertion that a schema would improve interoperability of microformats.
There are several problems with this assertion that are best described with questions:
What is the real world interoperability problem that you are trying to solve?
Do you have test cases that have been demonstrated to fail in specific implementations?
Do you have analysis that demonstrates that such problems stem from a lack of an explicit typed schema?
Lacking that, it is not logical to conclude that a schema would help improve interoperability.
schema incompleteness problem
Somewhat related to the schema interoperability misconception noted above, advocates of schemas in general often make the implicit assumption that if they have a schema for something, it somehow means they've fully expressed that something, potentially in a way that can be "automatically" parsed, etc.
In practice, explicit schemas do not represent all (often not even most) of the semantics of a specific format. For example, the HTML4 DTDs contain a mere fraction of the constraints and semantics expressed by the HTML4 specification. A validator that only checks the rules expressed in the HTML DTD will fail to check numerous assertions and requirements made in the specification itself. This is the schema incompleteness problem. In short, having a set of rules from a framework (such as those expressed by a schema like a DTD) is not only in practice insufficient, but serves to give a false sense of completeness of description.
Thus with microformats we eschew trying to solve the general schema problem (others are trying much harder for much longer on that problem - e.g. XML Schema etc., and failing in practice - i.e. usage on the Web) for simple dictionaries instead.
There has been some value demonstrated in some scenarios (e.g. reading microformats into an RDF store, either directly or thru a GRDDL transform) to at least disambiguate the use of vocabulary, and back the terms used with URLs. Thus we have XMDP (XHTML Meta Data Profiles) which is sufficient to define terms and provide a URL for each.
articles
Article about microformats misconceptions:
- Microformats: Moving along with the evolution of the Web <http://csarven.ca/microformats-misconceptions> touches on:
- assumption of complexity
- prefering natural language processing
- assumption of language
- reusing names
- assumption of specific markup or tags
- assumption of separate files being better
- assumption of need to solve all our problems
- verbosity
- abuse of data
- internationalization
- accessibility