value-class-pattern-issues - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:34:10Z

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

← Older revision		Revision as of 16:34, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~Value Class Pattern Issues~~</entry-title>~~		{{DISPLAYTITLE:Value Class Pattern Issues}}

	This page documents issues with the [[value-class-pattern]] specification before 2016-06-20.		This page documents issues with the [[value-class-pattern]] specification before 2016-06-20.

Tantek: add new issues to mf2-issues github

2016-07-14T14:49:03Z

add new issues to mf2-issues github

@@ Line 1: / Line 1: @@
 <entry-title>Value Class Pattern Issues</entry-title>
-Open issues concerning the parsing of the value excerption pattern.
 __TOC__
 ==Open Issues==

BenWard: Updated title

2009-05-11T09:36:36Z

Updated title

← Older revision		Revision as of 09:36, 11 May 2009
Line 1:		Line 1:
	<entry-title>Value ~~Excerption~~ Pattern Issues</entry-title>		<entry-title>Value Class Pattern Issues</entry-title>
	Open issues concerning the parsing of the value excerption pattern.		Open issues concerning the parsing of the value excerption pattern.
	__TOC__		__TOC__

BenWard: value-excerption-pattern-issues moved to value-class-pattern-issues: Moving over the issues page to go with the renamed value-class-pattern

2009-05-11T09:34:13Z

value-excerption-pattern-issues moved to value-class-pattern-issues: Moving over the issues page to go with the renamed value-class-pattern

← Older revision	Revision as of 09:34, 11 May 2009
(No difference)

Tantek: added * value-excerption-dt-separation-test

2009-01-23T05:23:21Z

added * value-excerption-dt-separation-test

← Older revision		Revision as of 05:23, 23 January 2009
Line 84:		Line 84:
	* [[value-excerption-pattern]]		* [[value-excerption-pattern]]
	* [[value-excerption-pattern-brainstorming]]		* [[value-excerption-pattern-brainstorming]]
			* [[value-excerption-dt-separation-test]]
	* [[value-excerption-value-title-test]]		* [[value-excerption-value-title-test]]
	* [[machine-data]]		* [[machine-data]]

Tantek: added more related pages cross-links

2009-01-23T03:06:34Z

added more related pages cross-links

← Older revision		Revision as of 03:06, 23 January 2009
Line 83:		Line 83:

	* [[value-excerption-pattern]]		* [[value-excerption-pattern]]
			* [[value-excerption-pattern-brainstorming]]
			* [[value-excerption-value-title-test]]
	* [[machine-data]]		* [[machine-data]]

BenWard: /* Parsing title from Empty value Elements */ Moved issue -> brainstorm

2009-01-14T05:50:01Z

Parsing title from Empty value Elements: Moved issue -> brainstorm

@@ Line 61: / Line 61: @@
 ===Parsing <code>title</code> from Empty <code>value</code> Elements===
-As a solution to the invisible data requirements sometimes presented by [[machine-data]] in microformats, a parsing rule is proposed where the <code>value</code> element is <em>empty</em> (contains no non-whitespace characters), the <code>title</code> attribute instead be parsed.
+Moved to: [[value-excerption-pattern-brainstorming#parsing_title_from_empty_value_elements|value-excerption-pattern-brainstorming]]
 ===Parsing the value-excerption-pattern in combination with the ABBR-pattern===

BenWard: /* Resolution Notes */ Remove erroneous line break from quote.

2009-01-06T06:51:05Z

Resolution Notes: Remove erroneous line break from quote.

← Older revision		Revision as of 06:51, 6 January 2009
Line 78:		Line 78:
	*** Include something to effect of ‘parsers may attempt to validate the human form against the machine form’ (PHP has a human date parsing function, for example)		*** Include something to effect of ‘parsers may attempt to validate the human form against the machine form’ (PHP has a human date parsing function, for example)
	** Restrict opt-in to specific properties. Do not allow it to be parsed globally. Fail parsers which implement it globally.		** Restrict opt-in to specific properties. Do not allow it to be parsed globally. Fail parsers which implement it globally.
	* Regarding accessibility, have confirmation that the empty element will be ignored (''Thank you'': James Craig, Gez Lemon, Bruce Lawson): “JAWS and Window-Eyes announce the title attribute		* Regarding accessibility, have confirmation that the empty element will be ignored (''Thank you'': James Craig, Gez Lemon, Bruce Lawson): “JAWS and Window-Eyes announce the title attribute for an empty abbr is used and verbosity is set to ‘expand abbreviations’, but neither read the title attribute on an empty span.”
	for an empty abbr is used and verbosity is set to ‘expand abbreviations’, but neither read the title attribute on an empty span.”

	====Issues====		====Issues====

BenWard: Clean up. Added discussion/issues mark-up

2009-01-06T06:06:28Z

Clean up. Added discussion/issues mark-up

← Older revision		Revision as of 06:06, 6 January 2009
Line 1:		Line 1:
	<h1>Value Excerption Pattern Issues</h1>		<entry-title>Value Excerption Pattern Issues</entry-title>

	Open issues concerning the parsing of the value excerption pattern.		Open issues concerning the parsing of the value excerption pattern.
			__TOC__
	~~{{TOC-right}}~~

	==Open Issues==		==Open Issues==

Line 10:		Line 7:

	===Excluded Fields===		===Excluded Fields===
			<div class='discussion issues'>
	There seem to be some properties within which value excerpting is NOT allowed (or ''should not'' be allowed!) e.g. "type" in hCard. [[User:TobyInk\|TobyInk]] 07:38, 22 May 2008 (PDT)		* '''There seem to be some properties within which value excerpting is NOT allowed (or ''should not'' be allowed!)''' e.g. "type" in hCard. [[User:TobyInk\|TobyInk]] 07:38, 22 May 2008 (PDT)
	* You mean <code>type</code> as a sub-property of <code>tel</code>? That's one of the identified [[machine-data]] items that needs a means of including the publisher's choice text along with the microformat specified one. Not to conflate two separate issues, but just noting that separation of <code>type</code> text and <code>type value</code> needs to be handled somewhere, and value-excerption-pattern ''could'' be considered as part of the solution. [[User:BenWard\|BenWard]] 07:54, 22 May 2008 (PDT)		** You mean <code>type</code> as a sub-property of <code>tel</code>? That's one of the identified [[machine-data]] items that needs a means of including the publisher's choice text along with the microformat specified one. Not to conflate two separate issues, but just noting that separation of <code>type</code> text and <code>type value</code> needs to be handled somewhere, and value-excerption-pattern ''could'' be considered as part of the solution. [[User:BenWard\|BenWard]] 07:54, 22 May 2008 (PDT)
	* Some fields make sense to exclude this, as it seems unintuitive, and can be used to avoid many of nested-microformat problems that may avoid a messier mfo pattern. E.g. <code>entry-summary</code> and <code>entry-content</code> in [[hAtom]], both could very feasibly have nested formats or any kind, but doesn't strike me as useful to segregate into "value" at all. [[User:BenWard\|BenWard]] 10:41, 6 Jun 2008 (PDT)		** Some fields make sense to exclude this, as it seems unintuitive, and can be used to avoid many of nested-microformat problems that may avoid a messier mfo pattern. E.g. <code>entry-summary</code> and <code>entry-content</code> in [[hAtom]], both could very feasibly have nested formats or any kind, but doesn't strike me as useful to segregate into "value" at all. [[User:BenWard\|BenWard]] 10:41, 6 Jun 2008 (PDT)
	* Total other alternative, make value-excerption opt-in. Would need a bit of effort to go through all the specs and clarify, but actually might make more sense. It's a useful pattern for some properties (especially those with data patterns). [[User:BenWard\|BenWard]] 10:41, 6 Jun 2008 (PDT)		** Total other alternative, make value-excerption opt-in. Would need a bit of effort to go through all the specs and clarify, but actually might make more sense. It's a useful pattern for some properties (especially those with data patterns). [[User:BenWard\|BenWard]] 10:41, 6 Jun 2008 (PDT)
	* Setting the rules over depth-of-parsing (see below) to children-only would obviate the remaining need for this issue.		** Setting the rules over depth-of-parsing (see below) to children-only would obviate the remaining need for this issue.
			</div>

	===White-space behavior when concatenating value nodes===		===White-space behavior when concatenating value nodes===
			<div class='discussion issues'>
	We specify that no characters get inserted between concatenated occurrences of ‘value’. Need to audit all properties to ensure that this behavior would be correct in all cases.		* '''We specify that no characters get inserted between concatenated occurrences of ‘value’'''. Need to audit all properties to ensure that this behavior would be correct in all cases.
			** Possibly specify that individual properties can override this behavior, specifying a separator character.
	Possibly specify that individual properties can override this behavior, specifying a separator character. Possibly specify that this should be a provision of parsing implementations, so as to maintain flexibility for future publishing.		** Possibly specify that this should be a provision of parsing implementations, so as to maintain flexibility for future publishing.
			</div>

	===Depth of Parsing===		===Depth of Parsing===

	Currently any descendent is parsed, which causes issues if a microformat field using the value-excerption-pattern is nested within another.		'''Currently any descendent is parsed''', which causes issues if a microformat field using the value-excerption-pattern is nested within another.

	Example:		Example:
Line 53:		Line 52:

	Possible resolutions:		Possible resolutions:
			<div class="discussion">
	* Specify the <code>mfo</code> (‘microformat object’) class be used when nesting microformats, as a processing instruction to parsers not to parse unrelated nested items		* Specify the <code>mfo</code> (‘microformat object’) class be used when nesting microformats, as a processing instruction to parsers not to parse unrelated nested items
	* Specify that <code>value</code> must only be read from <em>children</em>, not from <em>all descendants</em>. Restrictive, unlikely to work for existing hCard TEL usage.		* Specify that <code>value</code> must only be read from <em>children</em>, not from <em>all descendants</em>. Restrictive, unlikely to work for existing hCard TEL usage.
	* Specify the above (<q>parse <em>children</em>, not <em>all descendants</em>), but allow individual properties (such as <code>tel</code> to override and parse all descendants. This would result in a parse-depth flag on all fields, and many getting overridden for all descendants, but again, seems to be a well structured solution. Property name dictionaries in parsers would have to include the depth flag with the property.		* Specify the above (<q>parse <em>children</em>, not <em>all descendants</em>), but allow individual properties (such as <code>tel</code> to override and parse all descendants. This would result in a parse-depth flag on all fields, and many getting overridden for all descendants, but again, seems to be a well structured solution. Property name dictionaries in parsers would have to include the depth flag with the property.
	** This may break existing published microformats. [[User:TobyInk\|TobyInk]] 07:25, 22 Jun 2008 (PDT)		** This may break existing published microformats. [[User:TobyInk\|TobyInk]] 07:25, 22 Jun 2008 (PDT)
			</div>

	===Parsing <code>title</code> from Empty <code>value</code> Elements===		===Parsing <code>title</code> from Empty <code>value</code> Elements===
Line 80:		Line 80:
	* Regarding accessibility, have confirmation that the empty element will be ignored (''Thank you'': James Craig, Gez Lemon, Bruce Lawson): “JAWS and Window-Eyes announce the title attribute		* Regarding accessibility, have confirmation that the empty element will be ignored (''Thank you'': James Craig, Gez Lemon, Bruce Lawson): “JAWS and Window-Eyes announce the title attribute
	for an empty abbr is used and verbosity is set to ‘expand abbreviations’, but neither read the title attribute on an empty span.”		for an empty abbr is used and verbosity is set to ‘expand abbreviations’, but neither read the title attribute on an empty span.”
	~~====Problems====~~

			====Issues====
			<div class="discussion issues">
	* '''Violates the microformats [[principle]] of visible data.''' Numerous previous efforts (e.g. markup in comments etc.) have walked down that path of "dark data" and failed in practice. We must hold ourselves to higher standards than any XML/RDF solution. It's part of what sets microformats apart from so many other failed efforts at data representation on the web. We must not go down the path of dark data. IMHO that principle is inviolable for [[microformats]]. [[User:Tantek\|Tantek]]		* '''Violates the microformats [[principle]] of visible data.''' Numerous previous efforts (e.g. markup in comments etc.) have walked down that path of "dark data" and failed in practice. We must hold ourselves to higher standards than any XML/RDF solution. It's part of what sets microformats apart from so many other failed efforts at data representation on the web. We must not go down the path of dark data. IMHO that principle is inviolable for [[microformats]]. [[User:Tantek\|Tantek]]
	** The approach here is that we have ''exceptional'' situations where we are requiring data to be duplicated for machines. They are exceptions which have existed in microformats since hCard, and this is a pattern to handle those exceptions and '''only''' those exceptions in response to the problems people have publishing them. The specification for this could be written to make it a per-property opt-in device, only for those properties identified above. ''This is not a ‘generic data embedding’ device'' and in line with the cited principals, should not be allowed to become one. --[[User:BenWard\|BenWard]] 05:17, 25 Jun 2008 (PDT)		** The approach here is that we have ''exceptional'' situations where we are requiring data to be duplicated for machines. They are exceptions which have existed in microformats since hCard, and this is a pattern to handle those exceptions and '''only''' those exceptions in response to the problems people have publishing them. The specification for this could be written to make it a per-property opt-in device, only for those properties identified above. ''This is not a ‘generic data embedding’ device'' and in line with the cited principals, should not be allowed to become one. --[[User:BenWard\|BenWard]] 05:17, 25 Jun 2008 (PDT)
Line 92:		Line 93:
	*** Tidy is not just used in parsers, but also by publishers, as part of CMSes, etc.		*** Tidy is not just used in parsers, but also by publishers, as part of CMSes, etc.
	* '''WYSIWYG editors''' - this might present a problem in these editors in terms of allowing the user to change the value of the title of an empty span. Some of them allow editing title attributes of some elements, namely <A>, <IMG> and not much more. Needs to be properly researched, but is this an issue? Should we care about default WYSIWYG deployments? Or leave that for microformats-aware WYSIWYG versions, they would allow editing this span somehow... [User:Andr3\|Andr3]] 04:38, 7 Nov 2008 (GMT)		* '''WYSIWYG editors''' - this might present a problem in these editors in terms of allowing the user to change the value of the title of an empty span. Some of them allow editing title attributes of some elements, namely <A>, <IMG> and not much more. Needs to be properly researched, but is this an issue? Should we care about default WYSIWYG deployments? Or leave that for microformats-aware WYSIWYG versions, they would allow editing this span somehow... [User:Andr3\|Andr3]] 04:38, 7 Nov 2008 (GMT)
			</div>

	===Parsing the value-excerption-pattern in combination with the ABBR-pattern===		===Parsing the value-excerption-pattern in combination with the ABBR-pattern===

	How does <code><span class="country-name"><abbr class="value" title="Great">G</abbr> <span class="value">Britain</span></span></code> parse?		<div class='discussion issues'>
			* How does <code><span class="country-name"><abbr class="value" title="Great">G</abbr> <span class="value">Britain</span></span></code> parse?
	* The main issue with this example is the lack of any explicit whitespace between the values. Under present parsing rules, this will parse as "GreatBritain". [[User:TobyInk\|TobyInk]] 15:20, 6 Jul 2008 (PDT)		** The main issue with this example is the lack of any explicit whitespace between the values. Under present parsing rules, this will parse as "GreatBritain". [[User:TobyInk\|TobyInk]] 15:20, 6 Jul 2008 (PDT)
			</div>

	==Closed Issues==		==Closed Issues==

AmeerDawood: /* Problems */

2008-11-17T23:48:06Z

Problems

← Older revision		Revision as of 23:48, 17 November 2008
Line 89:		Line 89:
	**The machine-data form is kept as a sibling of the human form, and in distance in code, is not much further away than the data stored on a single elements <code>title</code> attribute. Further, the specification for this could demand the value element be placed as the _first child_ of the parent property, forcing it to be published immediately after the property element. --[[User:BenWard\|BenWard]] 05:17, 25 Jun 2008 (PDT)		**The machine-data form is kept as a sibling of the human form, and in distance in code, is not much further away than the data stored on a single elements <code>title</code> attribute. Further, the specification for this could demand the value element be placed as the _first child_ of the parent property, forcing it to be published immediately after the property element. --[[User:BenWard\|BenWard]] 05:17, 25 Jun 2008 (PDT)
	* '''Some parsers may strip empty inline elements''' (particularly those that run incoming HTML through [http://tidy.sf.net Tidy] to convert it into well-formed XML). A workaround may be to allow (or even require) hard white space (i.e. <code>&nbsp;</code>) within the element with class='value".		* '''Some parsers may strip empty inline elements''' (particularly those that run incoming HTML through [http://tidy.sf.net Tidy] to convert it into well-formed XML). A workaround may be to allow (or even require) hard white space (i.e. <code>&nbsp;</code>) within the element with class='value".
	**It is, however, trivial to patch and build Tidy not to do this (keeping empty elements where that element also has a class attribute). Parser writers need to feed back on whether using a custom build is impossible to their solution, but since Tidy can be made to work, the problem can likely be alleviated. Ben Ward has put up an experimental build of Tidy with patched element-dropping ~~behaviour~~ here: [http://ben-ward.co.uk/files/tidy-microformats.zip tidy-microformats.zip]		**It is, however, trivial to patch and build Tidy not to do this (keeping empty elements where that element also has a class attribute). Parser writers need to feed back on whether using a custom build is impossible to their solution, but since Tidy can be made to work, the problem can likely be alleviated. Ben Ward has put up an experimental build of Tidy with patched element-dropping behavior here: [http://ben-ward.co.uk/files/tidy-microformats.zip tidy-microformats.zip]
	*** Tidy is not just used in parsers, but also by publishers, as part of CMSes, etc.		*** Tidy is not just used in parsers, but also by publishers, as part of CMSes, etc.
	* '''WYSIWYG editors''' - this might present a problem in these editors in terms of allowing the user to change the value of the title of an empty span. Some of them allow editing title attributes of some elements, namely <A>, <IMG> and not much more. Needs to be properly researched, but is this an issue? Should we care about default WYSIWYG deployments? Or leave that for microformats-aware WYSIWYG versions, they would allow editing this span somehow... [User:Andr3\|Andr3]] 04:38, 7 Nov 2008 (GMT)		* '''WYSIWYG editors''' - this might present a problem in these editors in terms of allowing the user to change the value of the title of an empty span. Some of them allow editing title attributes of some elements, namely <A>, <IMG> and not much more. Needs to be properly researched, but is this an issue? Should we care about default WYSIWYG deployments? Or leave that for microformats-aware WYSIWYG versions, they would allow editing this span somehow... [User:Andr3\|Andr3]] 04:38, 7 Nov 2008 (GMT)