namespaces-inconsistency-issue - Revision history

Tantek: noted that further confusion about namespaces is itself mostly a waste of time as well.

2009-08-14T15:15:16Z

noted that further confusion about namespaces is itself mostly a waste of time as well.

← Older revision		Revision as of 15:15, 14 August 2009
Line 1:		Line 1:
			= Clean-up needed =

			'''The very existence of this page, and the confusion in the below text re-affirms that anything to do with [[namespaces]] is confusing, and for the most part, a waste of time. For more on why this is a waste of time, see the [[namespaces]] page.''' - [[User:Tantek\|Tantek]] 15:15, 14 August 2009 (UTC)

			'''[[to-do]]: This page should be processed into a set of discrete individual issues on a page like [[namespaces-issues]]. This will enable better handling (through FAQs, changes to wiki text, etc.).''' - [[User:Tantek\|Tantek]] 15:15, 14 August 2009 (UTC)

	=Introduction=		=Introduction=

	This page outlines a disputed inconsistency that the Microformat's community has had for a number of years. Namely, in the way the community defines "namespace" and the position it takes against that definition of a namespace.		This page outlines a disputed inconsistency that the Microformat's community (note: nearly all of the below was authored by Manu Sporny, one person, and thus it is ''not'' representative of "the Microformat's (sic) community) has had for a number of years. Namely, in the way the community defines "namespace" and the position it takes against that definition of a namespace.

	=Brief Definitions=		=Brief Definitions=

WebOrganics: /* Sympathetic to the Cause */ Didn't unerstand topic

2008-09-21T14:13:45Z

Sympathetic to the Cause: Didn't unerstand topic

← Older revision		Revision as of 14:13, 21 September 2008
Line 218:		Line 218:
	* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)		* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)
	* [[User:Guillaume Lebleu\|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)		* [[User:Guillaume Lebleu\|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)
	* [[User:WebOrganics\|Martin McEvoy]] 14:04, 9 Feb 2008 (GMT)

	=Known anti-pattern=		=Known anti-pattern=

WebOrganics: /* Sympathetic to the Cause */

2008-02-09T14:05:34Z

Sympathetic to the Cause

← Older revision		Revision as of 14:05, 9 February 2008
Line 218:		Line 218:
	* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)		* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)
	* [[User:Guillaume Lebleu\|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)		* [[User:Guillaume Lebleu\|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)
			* [[User:WebOrganics\|Martin McEvoy]] 14:04, 9 Feb 2008 (GMT)

	=Known anti-pattern=		=Known anti-pattern=

Guillaume Lebleu: /* Sympathetic to the Cause */

2008-02-07T00:47:08Z

Sympathetic to the Cause

← Older revision		Revision as of 00:47, 7 February 2008
Line 217:		Line 217:

	* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)		* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)
			* [[User:Guillaume Lebleu\|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)

	=Known anti-pattern=		=Known anti-pattern=

AndyMabbett: /* Microformats as overlapping trees */ fmt

2008-02-06T10:44:45Z

Microformats as overlapping trees: fmt

← Older revision		Revision as of 10:44, 6 February 2008
Line 116:		Line 116:
	If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.		If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.

	*The "overlapping trees" model causes problems when (in the above example) ~~ether~~ are two, different URLs:		*The "overlapping trees" model causes problems when (in the above example) there are two, different URLs:

	:<pre><nowiki>		::<pre><nowiki>
	<a href="example.com/johndoe">John Doe</a>		<a href="example.com/johndoe">John Doe</a>
	would like to invite you to		would like to invite you to
Line 124:		Line 124:
	</nowiki></pre>		</nowiki></pre>

	If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared. This has already been an issue for me, on live pages. [[User:AndyMabbett\|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)		:If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared. This has already been an issue for me, on live pages. [[User:AndyMabbett\|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)

	==Microformats Do Not Use Fully Qualified Namespaces==		==Microformats Do Not Use Fully Qualified Namespaces==

AndyMabbett: /* Microformats as overlapping trees */ fmt

2008-02-06T10:43:59Z

Microformats as overlapping trees: fmt

← Older revision		Revision as of 10:43, 6 February 2008
Line 118:		Line 118:
	*The "overlapping trees" model causes problems when (in the above example) ether are two, different URLs:		*The "overlapping trees" model causes problems when (in the above example) ether are two, different URLs:

	:<pre><nowiki><a href="example.com/johndoe">John Doe</a> would like to invite you to <a href="example.net/widget-event">a meeting about widgets</a> on...</nowiki></pre>		:<pre><nowiki>
			<a href="example.com/johndoe">John Doe</a>
			would like to invite you to
			<a href="example.net/widget-event">a meeting about widgets</a> on...
			</nowiki></pre>

	If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared.. [[User:AndyMabbett\|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)		If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared. This has already been an issue for me, on live pages. [[User:AndyMabbett\|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)

	==Microformats Do Not Use Fully Qualified Namespaces==		==Microformats Do Not Use Fully Qualified Namespaces==

AndyMabbett: /* Microformats as overlapping trees */ problem with overlaps

2008-02-06T10:42:42Z

Microformats as overlapping trees: problem with overlaps

← Older revision		Revision as of 10:42, 6 February 2008
Line 115:		Line 115:

	If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.		If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.

			*The "overlapping trees" model causes problems when (in the above example) ether are two, different URLs:

			:<pre><nowiki><a href="example.com/johndoe">John Doe</a> would like to invite you to <a href="example.net/widget-event">a meeting about widgets</a> on...</nowiki></pre>

			If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared.. [[User:AndyMabbett\|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)

	==Microformats Do Not Use Fully Qualified Namespaces==		==Microformats Do Not Use Fully Qualified Namespaces==

Brian: Microformats as overlapping trees

2008-02-06T09:46:12Z

Microformats as overlapping trees

← Older revision		Revision as of 09:46, 6 February 2008
Line 110:		Line 110:

	The example above uses "entry" as the emulated namespace identifier. The claim that "entry" is a namespace is contested by the primary editor of hAtom. However, "If it quacks like a duck, walks like a duck, and looks like a duck - it's a duck."		The example above uses "entry" as the emulated namespace identifier. The claim that "entry" is a namespace is contested by the primary editor of hAtom. However, "If it quacks like a duck, walks like a duck, and looks like a duck - it's a duck."

			==Microformats as overlapping trees==
			Microformats attempt to use a single vocabulary. Therefore, properties like URL, have one definition across all formats, it makes little sense to have hcard:url, hreview:url, hcalendar:url, etc. They all mean the same thing, therefore there is no reason to group them, scope them or namespace them. If you think of each format as a tree structure mapped onto HTML elements, some portions of various trees will overlap and share branches. Scoping and namespacing would prevent these things from happening, but they occur in microformats all the time.

			If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.

	==Microformats Do Not Use Fully Qualified Namespaces==		==Microformats Do Not Use Fully Qualified Namespaces==

EdwardOConnor: anti-pattern

2008-02-05T19:44:38Z

anti-pattern

← Older revision		Revision as of 19:44, 5 February 2008
Line 202:		Line 202:

	* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)		* [[User:ManuSporny\|ManuSporny]] 07:54, 5 Feb 2008 (PST)

			=Known anti-pattern=

			Below is a list of people who believe the namespace anti-pattern has already been adequately addressed in [[namespaces]].

			* [[User:EdwardOConnor\|hober]] 11:44, 5 Feb 2008 (PST)

	= Resolution =		= Resolution =

ManuSporny: /* Microformats Do Not Use Fully Qualified Namespaces */

2008-02-05T17:09:39Z

Microformats Do Not Use Fully Qualified Namespaces

← Older revision		Revision as of 17:09, 5 February 2008
Line 115:		Line 115:
	There is agreement on Microformats not using fully qualified namespaces. For example, this is verboten:		There is agreement on Microformats not using fully qualified namespaces. For example, this is verboten:

			Example 8:
	<pre>		<pre>
	<div xmlns:vc="http://microformats.org/wiki/vcard-namespace#" class="vc:vcard">		<div xmlns:vc="http://microformats.org/wiki/vcard-namespace#" class="vc:vcard">
Line 121:		Line 122:
	</pre>		</pre>

	The above example uses a [http://en.wikipedia.org/wiki/Qname QName] to specify a fully qualified namespace for the FN class in the VCARD container. This is confusing for beginners, and difficult to author.		The above example uses a [http://en.wikipedia.org/wiki/Qname QName] to specify a fully qualified namespace for the FN class in the VCARD container. This is confusing for beginners, and difficult to author. The difficulty in understanding fully qualified namespaces, and the difficulty in authoring fully qualified namespaces are the primary reasons that fully qualified namespaces are not used in Microformats.

	=Definitions=		=Definitions=