misconceptions - Revision history

Tantek: add articles about misconceptions section, cite csarven article and list topics it coveres

2015-09-03T19:48:45Z

add articles about misconceptions section, cite csarven article and list topics it coveres

@@ Line 100: / Line 100: @@
 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.
 == see also ==
 * [[faq]]

Tantek: added misconception re: context vs namespaces

2008-02-04T06:17:24Z

added misconception re: context vs namespaces

← Older revision		Revision as of 06:17, 4 February 2008
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 ===

Tantek: added schema would improve interoperability of microformats misconception and schema incompleteness problem

2007-11-25T07:38:19Z

added schema would improve interoperability of microformats misconception and schema incompleteness problem

← Older revision		Revision as of 07:38, 25 November 2007
Line 69:		Line 69:

	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.		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.

	== see also ==		== see also ==

Tantek: added misconception: current behaviors and usage patterns in general

2007-11-06T22:38:58Z

added misconception: current behaviors and usage patterns in general

← Older revision		Revision as of 22:38, 6 November 2007
Line 51:		Line 51:

	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.

	== see also ==		== see also ==

Tantek: link to inevitably related namespaces-considered-harmful

2007-10-25T19:36:17Z

link to inevitably related namespaces-considered-harmful

← Older revision		Revision as of 19:36, 25 October 2007
Line 55:		Line 55:
	* [[faq]]		* [[faq]]
	* [[xmdp]]		* [[xmdp]]
			* [[namespaces-considered-harmful]]
	* [[criticism]]		* [[criticism]]

AndyMabbett: /* microformats use non URI based extensibility */ I found a response

2007-10-05T16:15:21Z

microformats use non URI based extensibility: I found a response

← Older revision		Revision as of 16:15, 5 October 2007
Line 28:		Line 28:

	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 ===

Tantek: link

2007-09-27T23:23:15Z

link

← Older revision		Revision as of 23:23, 27 September 2007
Line 44:		Line 44:
	''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.

Tantek: broke out additional profile text as a mix of misconception and moved one to criticism.

2007-09-27T22:48:33Z

broke out additional profile text as a mix of misconception and moved one to criticism.

← Older revision		Revision as of 22:48, 27 September 2007
Line 5:		Line 5:
	== misconceptions ==		== misconceptions ==

	=== microformats use non-URI based extensibility ===		=== 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. <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.

			=== microformats use non URI based extensibility ===
	misconception: ''Microformats use non-URI based extensibility.''		misconception: ''Microformats use non-URI based extensibility.''

Line 14:		Line 23:
	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).		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).

	~~However, missing~~ a DOCTYPE does little or no damage, as (modulo tag soup issues) the ~~DOCTYE~~ is a link in the chain of reasoning about what the document means. ~~The~~ HTML profile for microformats is however a crucial link.		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.
	~~There~~ are ~~two dangers is it is omitted:~~

	~~One danger 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~~.		However, despite how browsers make good sense of HTML sans DOCTYPEs today, witness how nearly no general <em>user-centric</em> 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 <em>use</em> the profile attribute for microformats, and encourage its use.

	The ~~other danger 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. Web client software has to be all updated for the latest microformats which they want to support~~. ~~While this would scale for~~ a ~~small number~~ of ~~well~~-~~known global microformats, it does not scale when domain~~-~~specific, or culture-specific, or company-specific microformats are added~~.		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.

	It is ~~therefore important~~ to ~~<em>use</em>~~ the ~~profile attribute~~.		=== 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. '''

	~~The [http://www.w3.org/2003/g/data-view GRDDL] spec shows how to make a profile,~~ and ~~how generic data clients~~ to ~~follow,~~ to ~~ground the data into RDF. 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~~.		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.

	=== ~~microformats use unscoped class names~~ ===		=== no generic data gathering device can be built ===
	~~misconception:~~ ''~~Microformats definitions~~ use ~~unqualified/scoped class attribute strings as semantic tags~~.''		''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 <em>has</em> 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.''

	~~This~~ is ~~incorrect on two counts~~.		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.

	~~First, as above, 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~~.		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.

	~~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.		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.

	== see also ==		== see also ==
	* [[faq]]		* [[faq]]
	* [[xmdp]]		* [[xmdp]]
			* [[criticism]]

TimBl: Add links

2007-09-27T19:37:10Z

Add links

← Older revision		Revision as of 19:37, 27 September 2007
Line 23:		Line 23:
	It is therefore important to <em>use</em> the profile attribute.		It is therefore important to <em>use</em> the profile attribute.

	The GRDDL spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. 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.		The [http://www.w3.org/2003/g/data-view GRDDL] spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. 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.

	=== microformats use unscoped class names ===		=== microformats use unscoped class names ===

TimBl: Elaborate two dangers of not using profiles.

2007-09-27T17:27:06Z

Elaborate two dangers of not using profiles.

← Older revision		Revision as of 17:27, 27 September 2007
Line 13:		Line 13:

	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).		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).

			However, missing a DOCTYPE does little or no damage, as (modulo tag soup issues) the DOCTYE is a link in the chain of reasoning about what the document means. The HTML profile for microformats is however a crucial link.
			There are two dangers is it is omitted:

			One danger 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.

			The other danger 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. Web client software has to be all updated for the latest microformats which they want to support. While this would scale for a small number of well-known global microformats, it does not scale when domain-specific, or culture-specific, or company-specific microformats are added.

			It is therefore important to <em>use</em> the profile attribute.

			The GRDDL spec shows how to make a profile, and how generic data clients to follow, to ground the data into RDF. 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 use unscoped class names ===		=== microformats use unscoped class names ===