hcard-parsing-brainstorming - Revision history

Tantek: /* tel parsing */ nice to haves, generator, validator

2010-07-24T23:16:30Z

tel parsing: nice to haves, generator, validator

← Older revision		Revision as of 23:16, 24 July 2010
Line 293:		Line 293:

	== tel parsing ==		== tel parsing ==
	* ignore (0) in tel property values		* '''ignore (0) in tel property values'''
	** e.g. British/UK telephone numbers often have a (0) in them to indicate how to dial #s locally.		** e.g. British/UK telephone numbers often have a (0) in them to indicate how to dial #s locally.

	* introduce 'tel' as a special type, so that it can trigger parsing for "tel:" URLs in <code>a href</code> elements.		* '''introduce 'tel' as a special type,''' so that it can trigger parsing for "tel:" URLs in <code>a href</code> elements.
	** as well as incorporate the special "ignore (0)" rule above.		** as well as incorporate the special "ignore (0)" rule above.

			Some nice to haves (parser related only in that they may require additional parsing related code)
			* tel content to markup generator that generates the "tel:" URL
			** could incorporate into the hCard Creator.
			* tel validator

	==See also==		==See also==
	{{hcard-related-pages}}		{{hcard-related-pages}}

Tantek: fixed some heading levels, tel ignore (0) variant, tel as potentially a special type to trigger "tel:" URL parsing from a href

2010-07-24T23:12:14Z

fixed some heading levels, tel ignore (0) variant, tel as potentially a special type to trigger "tel:" URL parsing from a href

← Older revision		Revision as of 23:12, 24 July 2010
Line 25:		Line 25:
	[[User:Tantek\|Tantek]]		[[User:Tantek\|Tantek]]

	=== forms auto-fill ===		== forms auto-fill ==
	If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".		If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Line 38:		Line 38:
	[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)		[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)

	==== input examples ====		=== input examples ===
	See [[hcard-input-examples]] for research on examples of contact info input forms.		See [[hcard-input-examples]] for research on examples of contact info input forms.

Line 45:		Line 45:
	* hCard copy and paste (pasting in particular)		* hCard copy and paste (pasting in particular)

	==== blog posts on hCard forms fill ====		=== blog posts on hCard forms fill ===
	For more on this, see the following blog posts:		For more on this, see the following blog posts:
	* 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.		* 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.
	* 2008-03-04 blog post [http://microformatique.com/?p=228 Fill in those pesky forms with hCards] by John Allsopp, author of the microformats [[book]] "[http://tr.im/ufbook Microformats: Empowering Your Markup for Web 2.0]".		* 2008-03-04 blog post [http://microformatique.com/?p=228 Fill in those pesky forms with hCards] by John Allsopp, author of the microformats [[book]] "[http://tr.im/ufbook Microformats: Empowering Your Markup for Web 2.0]".

	==== related implementations ====		=== related implementations ===
	* http://shapeshed.com/examples/hcardme/ - open source and a page that demonstrates entering a URL and importing hCard contact info from that URL into the form on the page.		* http://shapeshed.com/examples/hcardme/ - open source and a page that demonstrates entering a URL and importing hCard contact info from that URL into the form on the page.

			=== background discussion ===
	==== background discussion ====

	Key threads:		Key threads:
Line 71:		Line 70:
	The options discussed in a hypothetical hCard input system from that post:		The options discussed in a hypothetical hCard input system from that post:

	==== option new vcard input root class ====		=== option new vcard input root class ===
	1) create a new root class other than vcard to indicate a form that's		1) create a new root class other than vcard to indicate a form that's
	fillable with hCard data.		fillable with hCard data.
Line 98:		Line 97:
	</div>		</div>

	==== option add input elements to hCard parsing ====		=== option add input elements to hCard parsing ===
	2) extend hCard's parsing rules to cover form elements and relying on		2) extend hCard's parsing rules to cover form elements and relying on
	the FORM/INPUT semantics to indicate that stuff is inputtable.		the FORM/INPUT semantics to indicate that stuff is inputtable.
Line 131:		Line 130:
	See discussion points for more details and follow-up on benefits / drawbacks.		See discussion points for more details and follow-up on benefits / drawbacks.

	==== forms auto fill for all microformats ====		=== forms auto fill for all microformats ===
	Broader question:		Broader question:
	<div class="discussion">		<div class="discussion">
Line 138:		Line 137:
	</div>		</div>

	==== discussion points ====		=== discussion points ===
	Many raised by [[User:RobManson\|RobManson]].		Many raised by [[User:RobManson\|RobManson]].

Line 292:		Line 291:
	[[User:Tantek\|Tantek]] 09:20, 2 Aug 2007 (PDT)		[[User:Tantek\|Tantek]] 09:20, 2 Aug 2007 (PDT)


			== tel parsing ==
			* ignore (0) in tel property values
			** e.g. British/UK telephone numbers often have a (0) in them to indicate how to dial #s locally.

			* introduce 'tel' as a special type, so that it can trigger parsing for "tel:" URLs in <code>a href</code> elements.
			** as well as incorporate the special "ignore (0)" rule above.

	==See also==		==See also==
	{{hcard-related-pages}}		{{hcard-related-pages}}

Tantek: /* auto-fill examples */ note input examples, goal to enable multiple use cases, hCard forms auto-fill and hCard copy+paste

2009-06-09T23:03:46Z

auto-fill examples: note input examples, goal to enable multiple use cases, hCard forms auto-fill and hCard copy+paste

← Older revision		Revision as of 23:03, 9 June 2009
Line 38:		Line 38:
	[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)		[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)

	==== ~~auto-fill~~ examples ====		==== input examples ====
	* See [[hcard-~~auto-fill~~-examples]] for research on examples of contact info forms ~~that would benefit from~~ hCard auto-fill.		See [[hcard-input-examples]] for research on examples of contact info input forms.

			By specifying a consistent way to markup contact info (person or venue/organization) input forms, we could enable both:
			* hCard forms auto-fill
			* hCard copy and paste (pasting in particular)

	==== blog posts on hCard forms fill ====		==== blog posts on hCard forms fill ====

Tantek: link to hcard-auto-fill-examples to start documenting real world sites that have contact input forms to use as a better basis for hCard forms auto-fill brainstorming

2009-06-09T18:20:32Z

link to hcard-auto-fill-examples to start documenting real world sites that have contact input forms to use as a better basis for hCard forms auto-fill brainstorming

← Older revision		Revision as of 18:20, 9 June 2009
Line 37:		Line 37:

	[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)		[[User:Tantek\|Tantek]] 16:24, 23 Jul 2007 (PDT)

			==== auto-fill examples ====
			* See [[hcard-auto-fill-examples]] for research on examples of contact info forms that would benefit from hCard auto-fill.

	==== blog posts on hCard forms fill ====		==== blog posts on hCard forms fill ====

Tantek: balance discussion div with end tag

2009-06-08T19:22:26Z

balance discussion div with end tag

← Older revision		Revision as of 19:22, 8 June 2009
Line 174:		Line 174:
	*** -1 (unattributed, perhaps rhetorical) hypothetical comment assuming more complexity beyond.		*** -1 (unattributed, perhaps rhetorical) hypothetical comment assuming more complexity beyond.
	** -1 requiring javascript is a non-starter. microformats must work as [[POSH]]. [[User:Tantek\|Tantek]] 19:17, 8 June 2009 (UTC)		** -1 requiring javascript is a non-starter. microformats must work as [[POSH]]. [[User:Tantek\|Tantek]] 19:17, 8 June 2009 (UTC)
			</div>

	== multiple type parsing ==		== multiple type parsing ==

Tantek: /* forms auto fill */ restore heading with dash - appears to work nicely without escaping

2009-06-08T19:18:52Z

forms auto fill: restore heading with dash - appears to work nicely without escaping

← Older revision		Revision as of 19:18, 8 June 2009
Line 25:		Line 25:
	[[User:Tantek\|Tantek]]		[[User:Tantek\|Tantek]]

	=== forms auto fill ===		=== forms auto-fill ===
	If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".		If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Tantek: updated forms auto fill section with additional citations, organized headings and grouped subsections more sensibly, added opinions

2009-06-08T19:17:58Z

updated forms auto fill section with additional citations, organized headings and grouped subsections more sensibly, added opinions

Show changes

AndyMabbett at 17:01, 17 January 2008

2008-01-17T17:01:10Z

New page

= Brainstorming for hCard parsing =

See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules; and [[hcard-brainstorming]] for more general discussion.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

== Additional Semantic HTML handling ==
=== <code>acronym</code> element handling ===
Choices:
* Explicitly treat <code>acronym</code> the same as <code>abbr</code>, per semantics of the '<code>title</code>' attribute on <code>acronym</code> in particular, as defined in HTML4.01.
* Explicitly treat <code>acronym</code> the same as <code>span</code>, and discourage use of <code>acronym</code>.

=== <code>input</code> element handling ===
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the <code>img</code> element use the 'alt' attribute.

One element I forgot at the time was the <code>input</code> element, specifically, <code><nowiki><input type="text"></nowiki></code>. Another I forgot was the <code>textarea</code> element.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
** consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
* <code><textarea></code>: use the text contents of the element. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.

[[User:Tantek|Tantek]]

=== forms auto-fill ===
If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. [[operator]] on [[firefox]]) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in [[Firefox]] and [[IE]], and any other browsers that support it.

For more on this, see the 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

'''[[i18n]]''' advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)

=== Background discussion: ===

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

=== Key Issues/discussion points ===
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- Unworkable. Cannot require clientside javascript.
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
- hypothetical comment assuming more complexity beyond.

[[User:RobManson|RobManson]]

== multiple type parsing ==
* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

== fax and modem hyperlink parsing ==
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

== Ambiguous name components ==

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

==ADR with no children==
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

=== implied single adr subproperty ===
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

=== implied adr subproperties ===
It may be possible for parsers to parse out adr subproperties from a contiguous adr string. This would be an optimization for both [[adr]] and [[hcard|hCard]].

This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.

Examples:

[http://www.ibm.com/contact/employees/us/ IBM's Employee Directory] search [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael returns hCards with the "adr" property] which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.:

<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>

We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:

* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'

Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.

E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries

The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.

There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]

=== adr without children FAQ ===
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)

Q: What should a parser do with an "adr" property lacking any subproperties?

A: A parser SHOULD do nothing with such an "adr" property. A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property. Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.

[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)

==See also==
{{hcard-related-pages}}