value-class-pattern: Difference between revisions
(→Parsing: Add a few comments) |
(→Parsing To-Do: Responses to TobyInk) |
||
Line 66: | Line 66: | ||
prettiness, I've added to the top. --> | prettiness, I've added to the top. --> | ||
* 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) | |||
* Clarify white-space behaviour when concatenating value nodes. | * Clarify white-space behaviour when concatenating value nodes. | ||
* Clarify depth of parsing. Currently any descendent is parsed, which causes issues if a property using the value-excerption-pattern is nested within another property. | * Clarify depth of parsing. Currently any descendent is parsed, which causes issues if a property using the value-excerption-pattern is nested within another property. | ||
** e.g. [[hCalendar]] defines <code>organiser</code>, which may be an [[hCard]], which may have a <code>tel</code> property containing a sub-property <code>value</code>. Under these parsing rules, the entire <code>organiser</code> field would be parsed as the telephone number. | ** e.g. [[hCalendar]] defines <code>organiser</code>, which may be an [[hCard]], which may have a <code>tel</code> property containing a sub-property <code>value</code>. Under these parsing rules, the entire <code>organiser</code> field would be parsed as the telephone number. | ||
*** [http://buzzword.org.uk/cognition/ Cognition] copes with this OK -- the organizer is parsed as a full contact with an hCard - not just a number. [[User:TobyInk|TobyInk]] 07:38, 22 May 2008 (PDT) | *** [http://buzzword.org.uk/cognition/ Cognition] copes with this OK -- the organizer is parsed as a full contact with an hCard - not just a number. [[User:TobyInk|TobyInk]] 07:38, 22 May 2008 (PDT) | ||
**** Ah, but if a parser were written just as an hCalendar parser, with no hCard support? Cognition already understands that hCard is something special. [[User:BenWard|BenWard]] 07:54, 22 May 2008 (PDT) | |||
** Would this still work if parsing value were restricted just to ''children'', rather than ''all descendants''? [[User:BenWard|BenWard]] 06:53, 22 May 2008 (PDT) | ** Would this still work if parsing value were restricted just to ''children'', rather than ''all descendants''? [[User:BenWard|BenWard]] 06:53, 22 May 2008 (PDT) | ||
*** This seems a little restrictive. [[User:TobyInk|TobyInk]] 07:38, 22 May 2008 (PDT) | *** This seems a little restrictive. [[User:TobyInk|TobyInk]] 07:38, 22 May 2008 (PDT) |
Revision as of 14:54, 22 May 2008
Value Excerption Pattern
The value excerption pattern is derived from value-excerpting in hCard. As such, it is already somewhat supported in parsers. However, the precise parsing behaviour is not yet finalised, so the pattern should be used only with extreme caution, and with the awareness that the editing of more precise parsing rules could impact your pages.
Sometimes, only a part of an element's content is used as the value of a microformat property. This may occur when a property has optional sub-properties, such as tel
in hCard. Other times, the most logical, semantic element for the property class name may include other content.
For these purposes, the special class name value
is used to excerpt out the relevant element content.
Simple Examples
Here is an hCard fragment for marking up a home phone number:
vCard:
<code>TEL;TYPE=HOME:+1.415.555.1212</code>
hCard:
<span class="tel">
<span class="type">Home</span>:
<span class="value">+1.415.555.1212</span>
</span>
In this case, the value of tel
is +1.415.555.1212
, not Home: +1.415.555.1212
.
Another example, this time using price
in hListing:
<span class="price">
I want to sell for
<span class="value">£15</span>
</span>
In this case, price
will parse as £15
, rather than as the entire sentence.
Another example, using dtstart
in hCalendar:
<span class="dtstart">
Friday 25th May, 6pm
<span class="value">2008-05-25T18:00:00+0100</span>
</span>
Whilst the entire string ‘Friday 25th May […]’ is semantically the date, it's the ISO 8601 encoded form alone which must be consumed by a microformats parser, so the value
class isolates it.
Parsing
Parsing rules need defining fully. As a starting point, it works roughly like this.
- Where an element with a microformat property class name has an descendant with class name
value
, parsers should read the inner-text of thevalue
element only, ignoring other text node descendants. - Where multiple descendants have a class name of
value
, they should be concatenated.
Knowledge of other microformats must not be a prerequisite of parsing a microformat using the value-excerption-pattern.
Parsing To-Do
- There seem to be some properties within which value excerpting is NOT allowed (or should not be allowed!) e.g. "type" in hCard. TobyInk 07:38, 22 May 2008 (PDT)
- You mean
type
as a sub-property oftel
? 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 oftype
text andtype value
needs to be handled somewhere, and value-excerption-pattern could be considered as part of the solution. BenWard 07:54, 22 May 2008 (PDT)
- You mean
- Clarify white-space behaviour when concatenating value nodes.
- Clarify depth of parsing. Currently any descendent is parsed, which causes issues if a property using the value-excerption-pattern is nested within another property.
- e.g. hCalendar defines
organiser
, which may be an hCard, which may have atel
property containing a sub-propertyvalue
. Under these parsing rules, the entireorganiser
field would be parsed as the telephone number.- Cognition copes with this OK -- the organizer is parsed as a full contact with an hCard - not just a number. TobyInk 07:38, 22 May 2008 (PDT)
- Ah, but if a parser were written just as an hCalendar parser, with no hCard support? Cognition already understands that hCard is something special. BenWard 07:54, 22 May 2008 (PDT)
- Cognition copes with this OK -- the organizer is parsed as a full contact with an hCard - not just a number. TobyInk 07:38, 22 May 2008 (PDT)
- Would this still work if parsing value were restricted just to children, rather than all descendants? BenWard 06:53, 22 May 2008 (PDT)
- This seems a little restrictive. TobyInk 07:38, 22 May 2008 (PDT)
- e.g. hCalendar defines
- Clarify nested values. Should these be allowed (in which case we'll need to decide how they must be parsed), or disallowed (in which case parsers may implement an algorithm to deal with them, but authors will be warned not to rely on unpredicatable parsing behaviour) e.g.
<p class="tel">
<b class="value"><span class="value">012345</span></b> </p> TobyInk 07:38, 22 May 2008 (PDT)