xmdp-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:35:33Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:35, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~XMDP Brainstorming~~</entry-title>~~		{{DISPLAYTITLE:XMDP Brainstorming}}

	== introduction ==		== introduction ==

Pfefferle: Undo revision 64711 by Silinix (Talk)

2014-12-16T09:11:41Z

Undo revision 64711 by Silinix (Talk)

← Older revision		Revision as of 09:11, 16 December 2014
Line 35:		Line 35:
	* number/fixed		* number/fixed
	* string		* string
	*[http://www.silinix.com video]

	TimBL also suggested location lat/long/altitude, however that's more of a composite type (e.g. [[geo]]) that is made of multiple atomic types		TimBL also suggested location lat/long/altitude, however that's more of a composite type (e.g. [[geo]]) that is made of multiple atomic types

Silinix: /* atomic types */

2014-12-10T14:00:36Z

atomic types

← Older revision		Revision as of 14:00, 10 December 2014
Line 35:		Line 35:
	* number/fixed		* number/fixed
	* string		* string
			*[http://www.silinix.com video]

	TimBL also suggested location lat/long/altitude, however that's more of a composite type (e.g. [[geo]]) that is made of multiple atomic types		TimBL also suggested location lat/long/altitude, however that's more of a composite type (e.g. [[geo]]) that is made of multiple atomic types

Tantek: add notes from requests for improvements/additions to XMDP in-person from TimBL at #tpac09

2009-11-05T01:16:02Z

add notes from requests for improvements/additions to XMDP in-person from TimBL at #tpac09

← Older revision		Revision as of 01:16, 5 November 2009
Line 9:		Line 9:

	Some of the below are probably better addressed as questions and/or issues and should be moved to those pages accordingly. -- [[User:Tantek\|Tantek]]		Some of the below are probably better addressed as questions and/or issues and should be moved to those pages accordingly. -- [[User:Tantek\|Tantek]]

			== requests from TimBL ==
			At the [http://www.w3.org/2009/11/TPAC/ 2009 W3C Technical Plenary] I (Tantek) had a conversation with Tim Berners-Lee about what he would like to see in XMDP to enable rich(er) translation into RDFSchema (RDFS).

			The following subsections represent my notes on specific asks/requests/feedback from Tim. [[User:Tantek\|Tantek]] 01:16, 5 November 2009 (UTC)

			=== labels ===

			* labels are useful for multiple languages
			* "fn" - is a property name
			* rdfs:label would be "formatted name" - but not a long explanation, e.g. also "nom" in French
			* ok to use existing HTML "lang" attribute and standard language codes
			* XMDP should offer labels for terms, with labels in specific (human) languages

			=== serve RDFS using conneg ===
			It would be useful/nice if requests to microformats profiles, e.g. http://microformats.org/profile/hcard - if made with the Accept header requesting the mime type of RDFS (conneg / content negotiation), would be returned as an automatic translation (perhaps using XSLT) of the XMDP to RDFS.

			=== aliasing ===
			TimBL likes to be able to say this term is the same as this other term.

			=== atomic types ===
			It would be useful to specify the atomic type of a microformats property, e.g. one of the following:
			* datetime
			* url/email
			* number/fixed
			* string

			TimBL also suggested location lat/long/altitude, however that's more of a composite type (e.g. [[geo]]) that is made of multiple atomic types

	== Possible XMDP Additions ==		== Possible XMDP Additions ==

Tantek: /* root class name identification */ clarify rejected solutions, note a possible solution

2009-10-04T19:22:00Z

root class name identification: clarify rejected solutions, note a possible solution

← Older revision		Revision as of 19:22, 4 October 2009
Line 26:		Line 26:

	=== root class name identification ===		=== root class name identification ===
			Use-case:

	It could be quite convenient for "generic/universal" microformat parsers if they could read an XMDP profile and understand which of the defined class names were ''root'' class names for microformats, and thus be able to distinguish those object boundaries.		It could be quite convenient for "generic/universal" microformat parsers if they could read an XMDP profile and understand which of the defined class names were ''root'' class names for microformats, and thus be able to distinguish those object boundaries.

			XMDP profiles can and do contain definitions for multiple root class names (e.g. http://microformats.org/wiki/hcard defines "vcard", "adr", and "geo").

			==== possible solutions ====
			===== XMDP definition flag =====
			Introduce some sort of markup or textual flag that indicates inside an XMDP definition (<dd>) for a class name that the class name may be used as a root class name.

			==== rejected solutions ====
			===== first class name defined in a profile =====
	One simple thought would be that the ''first'' class name defined in a profile		One simple thought would be that the ''first'' class name defined in a profile
	(e.g. [[hcard-profile]]) is the root class for that microformat. ~~Problems:~~		(e.g. [[hcard-profile]]) is the root class for that microformat.
	* What about an XMDP that defines multiple microformats?
	* What about a microformat that defines multiple possible root class names (e.g. [[hcalendar\|hCalendar]] permits "vcalendar" or "vevent", [[hatom\|hAtom]] permits "hfeed" or "hentry")?

	==== ~~a possible solution~~ ====		Critical problem(s):
			* Does not handle the case of multiple root class names in an XMDP. E.g. a microformat that defines multiple possible root class names (e.g. [[hcalendar\|hCalendar]] permits "vcalendar" or "vevent", [[hatom\|hAtom]] permits "hfeed" or "hentry").

			===== publisher linking to root class name =====
	The author including a reference to the XMDP could link directly to the root class name.		The author including a reference to the XMDP could link directly to the root class name.
	<pre><!-- This profile link indicates that "vcard" is a root class name. -->		<pre><!-- This profile link indicates that "vcard" is a root class name. -->
	<head profile="http://www.w3.org/2006/03/hcard#vcard"></pre>		<head profile="http://www.w3.org/2006/03/hcard#vcard"></pre>

	The problem is this moves the information of what is the root class to perhaps one of the worst places, which is in every reference to the XMDP, whereas the XMDP itself should be defining what is ~~the~~ root class.		Critical problem(s):
			* The problem is this moves the information of what is the root class to perhaps one of the worst places, which is in every reference to the XMDP, whereas the XMDP itself should be defining what is a root class.

	==== inline ~~alternative~~ ====		===== publisher inline additional class name =====
	Another possibility that may be worth exploring, is the ability to indicate inline in the code that a class name is the root class name for a microformat, rather than (or perhaps in addition to) the XMDP.		Another possibility that may be worth exploring, is the ability to indicate inline in the code that a class name is the root class name for a microformat, rather than (or perhaps in addition to) the XMDP.

Line 52:		Line 63:

	would indicate that the element with classname of "vcard" is the root of a microformatted piece of information.		would indicate that the element with classname of "vcard" is the root of a microformatted piece of information.

			Critical problem(s):
			* The problem is this moves the information of what is the root class to perhaps one of the worst places, which is in every instance of the microformat, whereas the XMDP itself should be defining what is a root class.

	Possible drawbacks:		Possible drawbacks:
	* ~~how~~ would you know which class name (other than "ufroot") was the root class name? e.g. <pre>class="vcard person ufroot"</pre>		* How would you know which class name (other than "ufroot") was the root class name? e.g. <pre>class="vcard person ufroot"</pre>
	** perhaps by only looking at classes defined in the XMDPs for the document.		** perhaps by only looking at classes defined in the XMDPs for the document.
	** perhaps by only allowing one root class name in addition to the "ufroot"		** perhaps by only allowing one root class name in addition to the "ufroot"
	** or perhaps by saying that all of the other class names in the same attribute are root class names (so that for example you could say: <pre><span class="root hreview hentry"></pre>		** or perhaps by saying that all of the other class names in the same attribute are root class names (so that for example you could say: <pre><span class="root hreview hentry"></pre>

	This is also very similar to the [[mfo]] problem.		This is also very similar to, but not the same as, the [[mfo]] problem, and should be considered in that context as an independent solution.

	=== linking to the XMDP ===		=== linking to the XMDP ===

Tantek: entry-title, rm explicit toc, add explicit see also to xmdp and related pages, rm explicit contributors - wiki history better documents this

2009-10-04T17:53:13Z

entry-title, rm explicit toc, add explicit see also to xmdp and related pages, rm explicit contributors - wiki history better documents this

← Older revision		Revision as of 17:53, 4 October 2009
Line 1:		Line 1:
	<h1>XMDP Brainstorming</h1>		<entry-title>XMDP Brainstorming</entry-title>

	~~{{TOC-right}}~~

	~~== contributors ==~~

	* [http://tantek.com/log/ Tantek Çelik]
	* [http://thecommunityengine.com/home Bud Gibson]
	* [[User:TobyInk\|Toby Inkster]]

	~~Add your name here if you make significant contributions to this page and wish to take responsibility for them.~~

	== introduction ==		== introduction ==

	Tantek Çelik developed [http://gmpg.org/xmdp/ XMDP] to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the [http://gmpg.org/xmdp/description XMDP spec], a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.		Tantek Çelik developed [http://gmpg.org/xmdp/ XMDP] to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the [http://gmpg.org/xmdp/description XMDP spec], a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.

	This page is for exploring possible additions / extensions to XMDP.		This page is for exploring possible additions / extensions to XMDP, contributed by numerous folks in the microformats community.

	See [[xmdp-faq]] and [[xmdp-issues]] for questions and issues.		See [[xmdp-faq]] and [[xmdp-issues]] for questions and issues.

			Some of the below are probably better addressed as questions and/or issues and should be moved to those pages accordingly. -- [[User:Tantek\|Tantek]]

	== Possible XMDP Additions ==		== Possible XMDP Additions ==

	=== resolving when microformats may be in use ===		=== resolving when microformats may be in use ===

	Currently the potential existence of microformats in a document can be declared by referencing the profile URLs for those microformats in the profile attribute of the head element of that document.		Currently the potential existence of microformats in a document can be declared by referencing the profile URLs for those microformats in the profile attribute of the head element of that document.

Line 131:		Line 119:
	* A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)		* A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)
	** Two things. First, "category" MUST NOT be different between hCard and hCalendar, and thus it is a feature, not a problem, that there can only be one id="category" between the two of them. Second, for the rel case, this is solved by using ID values prefixed with "rel-" for rel values. E.g. in http://gmpg.org/xmdp/1, rel-profile is defined with id="rel-profile", and the class name "profile" is defined with id="profile". [[User:Tantek\|Tantek]] 17:48, 4 October 2009 (UTC)		** Two things. First, "category" MUST NOT be different between hCard and hCalendar, and thus it is a feature, not a problem, that there can only be one id="category" between the two of them. Second, for the rel case, this is solved by using ID values prefixed with "rel-" for rel values. E.g. in http://gmpg.org/xmdp/1, rel-profile is defined with id="rel-profile", and the class name "profile" is defined with id="profile". [[User:Tantek\|Tantek]] 17:48, 4 October 2009 (UTC)
			</div>
	== automatic parsability enabling ==		== automatic parsability enabling ==

Line 157:		Line 145:

	== See Also ==		== See Also ==
			* [[xmdp]]
	[[~~Parsing Microformats~~]]		* [[xmdp-faq]]
			* [[xmdp-issues]]

Tantek: /* ID Attribute */ resolve ID attribute issue

2009-10-04T17:48:21Z

ID Attribute: resolve ID attribute issue

← Older revision		Revision as of 17:48, 4 October 2009
Line 128:		Line 128:

	== ID Attribute ==		== ID Attribute ==
			<div class="discussion">
	A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)		* A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)
			** Two things. First, "category" MUST NOT be different between hCard and hCalendar, and thus it is a feature, not a problem, that there can only be one id="category" between the two of them. Second, for the rel case, this is solved by using ID values prefixed with "rel-" for rel values. E.g. in http://gmpg.org/xmdp/1, rel-profile is defined with id="rel-profile", and the class name "profile" is defined with id="profile". [[User:Tantek\|Tantek]] 17:48, 4 October 2009 (UTC)

	== automatic parsability enabling ==		== automatic parsability enabling ==

Tantek: /* root class name identification */ added inline alternative possibility

2009-04-30T20:21:18Z

root class name identification: added inline alternative possibility

@@ Line 46: / Line 46: @@
 * What about a microformat that defines multiple possible root class names (e.g. [[hcalendar|hCalendar]] permits "vcalendar" or "vevent", [[hatom|hAtom]] permits "hfeed" or "hentry")?
-==== Another possible solution ====
+==== a possible solution ====
 <pre>&lt;!-- This profile link indicates that "vcard" is a root class name. -->
 &lt;head profile="http://www.w3.org/2006/03/hcard#vcard"></pre>
 === linking to the XMDP ===

Tantek: rm tying of a brainstorm to a version number - it's premature and bad practice to imply any specific brainstorm will go into any specific version, noted prev attempts at full parsability have failed

2008-07-30T18:21:26Z

rm tying of a brainstorm to a version number - it's premature and bad practice to imply any specific brainstorm will go into any specific version, noted prev attempts at full parsability have failed

← Older revision		Revision as of 18:21, 30 July 2008
Line 1:		Line 1:
	= XMDP Brainstorming =		<h1>XMDP Brainstorming</h1>

	~~__TOC__~~		{{TOC-right}}

	== ~~Authors~~ ==		== contributors ==

	* [http://tantek.com/log/ Tantek Çelik]		* [http://tantek.com/log/ Tantek Çelik]
	* [http://thecommunityengine.com/home Bud Gibson]		* [http://thecommunityengine.com/home Bud Gibson]
			* [[User:TobyInk\|Toby Inkster]]

	Add your name here if you make significant contributions to this page and wish to take responsibility for them.		Add your name here if you make significant contributions to this page and wish to take responsibility for them.

	== ~~Introduction~~ ==		== introduction ==

	Tantek Çelik developed [http://gmpg.org/xmdp/ XMDP] to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the [http://gmpg.org/xmdp/description XMDP spec], a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.		Tantek Çelik developed [http://gmpg.org/xmdp/ XMDP] to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the [http://gmpg.org/xmdp/description XMDP spec], a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.
Line 108:		Line 109:
	A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)		A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. <dt id="foo">foo</dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk\|TobyInk]] 06:26, 18 Feb 2008 (PST)

	== ~~Machine-Usable XMDP2~~ ==		== automatic parsability enabling ==

	The current XMDP is useful for people to read and learn about a microformat, but ~~not especially useful~~ to automate parsing microformats/[[poshformats]]. It would be nice if people could design their own poshformats, create an XMDP profile, and for the poshformat to be thus instantly parsable by machines. Here is the information that I think ~~a new version of~~ XMDP ~~(an "XMDP2") would require in order~~ for this to ~~happen~~:		The current XMDP is useful for people to read and learn about a microformat, but of very limited utility to automate parsing microformats/[[poshformats]] (simply identification of vocabulary to parse for, and what attributes to parse for them). It would be nice if people could design their own poshformats, create an XMDP profile, and for the poshformat to be thus instantly parsable by machines. Here is the information that I think would need to be added to XMDP for this to be possible:

	For each profile defined:		For each profile defined:

	* What ~~may be used~~ as a root ~~element?~~ (required)		* What is/are the root class name(s) (as previous brainstormed above: [[xmdp-brainstorming#root_class_name_identification\|root class name identification]]) of the microformats being defined by the XMDP (required)
	* What properties may ~~this root element contain~~? (required)		* What are the properties of each microformat? Or alternatively (and preferably), which microformat(s) may a property be used with? (to handle the common and encouraged case of vocabulary re-use across microformats) (required)

	For each property defined:		For each property defined:

	* Is it singular or plural? (Default: plural)
	* What datatype is it? (e.g. text, URI, datetime, duration, etc)
	* Might it contain a nested poshformat/microformat? If so, then this XMDP2 profile should link to the profile of the nested poshformat /microformat. (Multiple formats could be profiled on the same page, using ID attributes to link from one to the other.)
	* A human-readable description of what the property means (XMDP already has this)		* A human-readable description of what the property means (XMDP already has this)
	* What nested subproperties might be found within it? (Perhaps this could be indicated using a nested profile.)		* Is it a class/rel/id (or rev, but deprecated) value (XMDP already has this)
	* Is it a class/rel/rev/(other?) value? (Default: class)		* Is it singular or plural? (default: plural)
			* What datatype is it? (e.g. text, URI, email, datetime, duration. default:text)
			* Might it contain a nested poshformat/microformat? If so, then this profile should link to the profile of the nested poshformat /microformat. (Multiple formats could be defined in the same XMDP profile, using ID attributes to link from one to the other.)
			* What nested subproperties might be found within it? Or alternatively (and preferably), whether a property is actually a subproperty, and if so, which properties may it be used inside? (again, to handle the common and encouraged case of vocabulary re-use) (Perhaps this could be indicated using a nested profile.)

	~~There are probably~~ always ~~going to~~ be some parsing rules (e.g. hAtom's [http://microformats.org/wiki/hatom#Entry_Author "hunt the author" game]) which will not be expressible, but ~~I think that the above neatly covers~~ 90% of the information a parser should need for most microformats.		We must expect that there will always be some parsing rules (e.g. hAtom's [http://microformats.org/wiki/hatom#Entry_Author "hunt the author" game]) which will not be expressible in a machine readable profile format, but it may be possible to cover 90% of the information a parser should need for most microformats.

			Indeed experience has shown that any "real world" semantic markup languages that get significant use requires LOTS of special custom parsing rules (e.g. HTML is not fully parseable simply from the DTD, nor is RSS from the RSS DTD).

			Thus while it may make sense to take incremental steps towards capturing more about a microformat in XMDP, full enabling of machine parsability should not be a short-term (nor even medium-term) goal, as others have tried (DTD, RelaxNG, XML Schema) and failed to achieve this.

	== See Also ==		== See Also ==

	[[Parsing Microformats]]		[[Parsing Microformats]]

TobyInk: Machine-Usable XMDP

2008-07-30T12:38:23Z

Machine-Usable XMDP

@@ Line 107: / Line 107: @@
 A problem that I've had using XDMP is that it requires the use of the ID attribute (e.g. &lt;dt id="foo">foo&lt;/dt>) to define the term "foo". As (X)HTML only allows one element with any given ID, this raises problems if you need to define the same term multiple times -- e.g. to define "category" as a class within both hcard and hcalendar, or to define "copyright" as both a class value and a rel value. [[User:TobyInk|TobyInk]] 06:26, 18 Feb 2008 (PST)
 == See Also ==
 [[Parsing Microformats]]