value-class-pattern-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:33:58Z

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

← Older revision		Revision as of 16:33, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~value excerption pattern brainstorming~~</entry-title>~~		{{DISPLAYTITLE:value excerption pattern brainstorming}}

	''The [[value-excerption-pattern]] is derived from [[hCard#Value_excerpting\|value-excerpting]] in hCard. The precise parsing behavior is not yet finalized, so the pattern should be used only with extreme caution.''		''The [[value-excerption-pattern]] is derived from [[hCard#Value_excerpting\|value-excerpting]] in hCard. The precise parsing behavior is not yet finalized, so the pattern should be used only with extreme caution.''

Spiritquest: /* feedback */ added support to the brainstorm / proposal

2010-04-07T08:21:56Z

feedback: added support to the brainstorm / proposal

← Older revision		Revision as of 08:21, 7 April 2010
Line 131:		Line 131:

	* +1 [[User:Tantek\|Tantek]] 02:19, 7 April 2010 (UTC) (obviously, as the author :)		* +1 [[User:Tantek\|Tantek]] 02:19, 7 April 2010 (UTC) (obviously, as the author :)
	* ...		* +1 [[User:Spiritquest\|Ketan]] [[User:Spiritquest\|spiritquest]] 08:21, 7 April 2010 (UTC) (Quizzed Tantek about its use and the proposals above make sense.)

	Please feel free to provide additional input as well!		Please feel free to provide additional input as well!

Tantek: /* duration */ add feedback section to gather input

2010-04-07T02:19:26Z

duration: add feedback section to gather input

← Older revision		Revision as of 02:19, 7 April 2010
Line 123:		Line 123:

	===== duration property incorporation =====		===== duration property incorporation =====
	If this brainstorm proposal is accepted for the value class pattern, it would be even better if it was permitted directly on the "duration" property and incorporated as such into [[hCalendar]], [[hAudio]], and any other microformats specifications that have a "duration" property ([[hRecipe]]?).		If this brainstorm proposal is accepted for the value class pattern, it would be even better if it was permitted directly on the "duration" property and incorporated as such into [[hCalendar]] (i.e. into v1.0.1), [[hAudio]], and any other microformats specifications that have a "duration" property ([[hRecipe]]?).

	[[User:Tantek\|Tantek]] 02:12, 7 April 2010 (UTC)		[[User:Tantek\|Tantek]] 02:12, 7 April 2010 (UTC)

			===== feedback =====
			Please indicate your support/ambivalence/disapproval of this proposal with a +1/0/-1 followed by your name (use "<nowiki>~~~~</nowiki>") and optionally reasons for your opinion.

			* +1 [[User:Tantek\|Tantek]] 02:19, 7 April 2010 (UTC) (obviously, as the author :)
			* ...

			Please feel free to provide additional input as well!

			* ...

			Thanks, [[User:Tantek\|Tantek]]

	== Condensed <code>value-title</code> ==		== Condensed <code>value-title</code> ==

Tantek: created accepted and rejected sections, move earlier work on value class pattern to those sections, add new proposal on duration

2010-04-07T02:12:35Z

created accepted and rejected sections, move earlier work on value class pattern to those sections, add new proposal on duration

Show changes

BenWard: Documenting possible value-title optimisations.

2009-06-22T02:38:47Z

Documenting possible value-title optimisations.

@@ Line 399: / Line 399: @@
 * I believe there may have been a proposal for "usetitle"(link+citation needed) in the past that would function similarly.  I think "valuetitle" is better than "usetitle" as "valuetitle" is more *descriptive*, i.e. meaning "the title is the value", as opposed to "usetitle", which is more *prescriptive*, i.e. "use the title". [[User:Tantek|Tantek]] 08:13, 1 Sep 2008 (PDT)
 ** Agreed. ‘Processing instruction’ classenames are ugly and undesirable. Class should always be descriptive of the content. --[[User:BenWard|BenWard]] 05:42, 14 January 2009 (UTC)
 </div>

BenWard: value-excerption-pattern-brainstorming moved to value-class-pattern-brainstorming: Rename to value-class

2009-06-22T02:20:55Z

value-excerption-pattern-brainstorming moved to value-class-pattern-brainstorming: Rename to value-class

← Older revision	Revision as of 02:20, 22 June 2009
(No difference)

Tantek: /* date and time separation */ noted source of IRC discussions, rejected attempted theoretical extension of a specific concrete issue which was resolved for the specific examples given.

2009-05-02T00:51:38Z

date and time separation: noted source of IRC discussions, rejected attempted theoretical extension of a specific concrete issue which was resolved for the specific examples given.

← Older revision		Revision as of 00:51, 2 May 2009
Line 262:		Line 262:

	Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.		Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.

			issue:
			<div class="discussion">
	* hCard's <code>rev</code> is plural. [[User:TobyInk\|TobyInk]]		* hCard's <code>rev</code> is plural. [[User:TobyInk\|TobyInk]]
	** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?		** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?
	*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard\|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties\|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.		*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard\|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties\|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.
	**** ACCEPTED RESOLVED. The RFC states <~~pre~~><p>Type name: REV</p><p>Type purpose: To specify revision information about the current vCard.</p></~~pre~~> which thus implies the REV property applies to the entire vCard, not just portions thereof. I've updated the [[hcard#Singular_vs._Plural_Properties\|hCard singular properties accordingly]], and note that the [[hcard-singular-properties#rev\|explanation for why rev is singular]] was already updated - just added that same RFC text as quoted above. [[User:Tantek\|Tantek]] 00:36, 2 May 2009 (UTC)		**** ACCEPTED RESOLVED. The RFC states <blockquote><p>Type name: REV</p><p>Type purpose: To specify revision information about the current vCard.</p></blockquote> which thus implies the REV property applies to the entire vCard, not just portions thereof. I've updated the [[hcard#Singular_vs._Plural_Properties\|hCard singular properties accordingly]], and note that the [[hcard-singular-properties#rev\|explanation for why rev is singular]] was already updated - just added that same RFC text as quoted above. [[User:Tantek\|Tantek]] 00:36, 2 May 2009 (UTC)
			</div>

	===== reusing date data for multiple datetime properties =====		===== reusing date data for multiple datetime properties =====
Line 288:		Line 292:
	#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.		#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
	#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.		#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

			Much of the above was derived from [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 a lengthy discussion on IRC].

	==== discussion ====		==== discussion ====
	~~Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)~~

	<div class="discussion">		<div class="discussion">
	* regarding the [[datetime-design-pattern#advantages\|advantage]] of "and most importantly, introduces no dark data."		* regarding the [[datetime-design-pattern#advantages\|advantage]] of "and most importantly, introduces no dark data."
Line 299:		Line 303:
	***** That statement makes the mistake of conflating type data and content data. "tel" is not content data, just as <nowiki><p></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).		***** That statement makes the mistake of conflating type data and content data. "tel" is not content data, just as <nowiki><p></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
	****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.		****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.
			******* REJECTED THEORETICAL AND TANGENT. There is a clear distinction between type data and content data in the concrete examples of both HTML and hCard (and vCard from which it derived its distinctions). The expression of a "continuum" and the hypothetical examples given to justify the expression are all purely theoretical (rather than real and pragmatic), and thus are not worthy of being the basis of an issue. In addition, such a theoretical continuation of discussion is tangential to the original issue raised (publishers wanting to publish dark data), and thus is rejected on that basis as well. [[User:Tantek\|Tantek]] 00:51, 2 May 2009 (UTC)
	</div>		</div>

Tantek: /* time zones */ have processed IRC logs for this issue

2009-05-02T00:37:50Z

time zones: have processed IRC logs for this issue

← Older revision		Revision as of 00:37, 2 May 2009
Line 288:		Line 288:
	#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.		#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
	#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.		#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

	~~(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])~~

	==== discussion ====		==== discussion ====

Tantek: /* separate subtrees */ resolved hCard rev property singularity issue

2009-05-02T00:36:45Z

separate subtrees: resolved hCard rev property singularity issue

← Older revision		Revision as of 00:36, 2 May 2009
Line 265:		Line 265:
	** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?		** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?
	*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard\|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties\|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.		*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard\|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties\|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.
			**** ACCEPTED RESOLVED. The RFC states <pre><p>Type name: REV</p><p>Type purpose: To specify revision information about the current vCard.</p></pre> which thus implies the REV property applies to the entire vCard, not just portions thereof. I've updated the [[hcard#Singular_vs._Plural_Properties\|hCard singular properties accordingly]], and note that the [[hcard-singular-properties#rev\|explanation for why rev is singular]] was already updated - just added that same RFC text as quoted above. [[User:Tantek\|Tantek]] 00:36, 2 May 2009 (UTC)

	===== reusing date data for multiple datetime properties =====		===== reusing date data for multiple datetime properties =====

Tantek: /* issues */ updated handling of no tooltip requirement and maintaining proper sentences issue to then suggest use of value-title pattern.

2009-05-02T00:23:52Z

issues: updated handling of no tooltip requirement and maintaining proper sentences issue to then suggest use of value-title pattern.

← Older revision		Revision as of 00:23, 2 May 2009
Line 197:		Line 197:
	## Finally, it should not be our goal to try to satisfy every publisher, for that would make every microformat beholden to every publisher and contort the design of microformats in really poor ways. We must accept that not all publishers will adopt all microformats and that is ok. Our goal to incrementally increase the number of publishers that adopt microformats, not to try to satisfy each and every one.		## Finally, it should not be our goal to try to satisfy every publisher, for that would make every microformat beholden to every publisher and contort the design of microformats in really poor ways. We must accept that not all publishers will adopt all microformats and that is ok. Our goal to incrementally increase the number of publishers that adopt microformats, not to try to satisfy each and every one.
	# You have to have a tooltip though. It’s not possible to not have a tooltip. Not great.--[[User:JulianStahnke\|Julian Stahnke]] 12:58, 4 Sep 2008 (BST)		# You have to have a tooltip though. It’s not possible to not have a tooltip. Not great.--[[User:JulianStahnke\|Julian Stahnke]] 12:58, 4 Sep 2008 (BST)
	#* ~~Doesn't~~ a ~~nested span with empty title attribute work? e.g. <code><nowiki><span title="">...</span></nowiki></code>~~		#* If it is a requirement for the publisher that no tooltip whatsoever be displayed, then the publisher should consider using [[value-class-pattern#Using_value-title_to_publish_machine-data\|value-title]] to publish the data in an empty first-child span as specified in the [[value-class-pattern#Using_value-title_to_publish_machine-data\|value-title pattern]].
	#** Nope, empty title on nested element didn’t override a title on the ~~containing element when I tested~~ in ~~Safari 3 and Firefox 3. Browser would still display~~ the title.
	* Semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted.		* Semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted.
	*# Semantic stretch not misuse. It is a semantic abbreviation rather than a purely syntactical (character shortening) abbreviation, but it is an abbreviation in context nonetheless. Though this may stretch what may be commonly expected as an "abbreviation", the HTML4 spec does seem to allow some flexibility here ([http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 HTML 4.01 9.2.1 Phrase elements]).		*# Semantic stretch not misuse. It is a semantic abbreviation rather than a purely syntactical (character shortening) abbreviation, but it is an abbreviation in context nonetheless. Though this may stretch what may be commonly expected as an "abbreviation", the HTML4 spec does seem to allow some flexibility here ([http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 HTML 4.01 9.2.1 Phrase elements]).
	* Maintaining proper sentences with the expanded form. It is not always possible to use this mark-up and maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. And thus audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."		* Maintaining proper sentences with the expanded form. It is not always possible to use this mark-up and maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. And thus audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."
	*# ~~This~~ can ~~and should~~ be addressed by improving authoring examples ~~so that~~ practices improve with experience.		*# In some cases this can be addressed by improving authoring examples, and helping practices improve with experience.
			*# Alternatively, for cases like these, the [[value-class-pattern#Using_value-title_to_publish_machine-data\|value-title pattern]] can be used to include the precise ISO8601 date or datetime immediately adjacent to the informal date or datetime reference like "today" or "tonight".
	* Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae\|Phae]] 04:30, 27 Jun 2008 (PDT)		* Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae\|Phae]] 04:30, 27 Jun 2008 (PDT)
	*# Without specific citations of which authors and what specific issues they have, we are unable to address their issues.		*# Without specific citations of which authors and what specific issues they have, we are unable to address their issues.