[uf-dev] Defining and Extending Value Excepting

Ben Ward lists at ben-ward.co.uk
Fri Jun 6 11:37:20 PDT 2008

Hey guys,

I've tried to move this on a bit.

I've clarified the ‘no nesting value inside value’ discussion under  
the parsing bullet points, see http://microformats.org/wiki/value-excerption-pattern

I've also moved the ‘parsing to-do’ section off that page and pushed  
it onto a proper -issues page for the pattern. I've restructured that  
from the discussions, so we've something to focus on there now.

Since it's better organised now, and by extension better organised for  
wider feedback, I'm going to publicise the existence of these pages on  
uf-discuss and invite the wider community to raise other issues.

Concerning the current open issues, I'd like to draw your attentions  
to my most recent notes on them, see what you think.

* Excluded Fields (http://microformats.org/wiki/value-excerption-pattern-issues#Excluded_Fields 

We've been thinking in terms of excluding particular fields from being  
used with value excerpting. What if we flipped it? Make it opt-in for  
particular fields? Have each spec clarify ‘this field _may_  be used  
with value excerpting. That way, large fields like hAtom's entry- 
title, where value-excerpting has no (ahem) ‘value’, won't be affected  
by it _and_ this would actually allow many of the problems with  
nesting microformats to be avoided without need for an ‘mfo’-like  
class processing instruction.

* Depth of Parsing (http://microformats.org/wiki/value-excerption-pattern-issues#Depth_of_Parsing 

Currently parsing all descendants can cause the nested-microformat- 
value-overwriting-potential-world-of-pain issue, an MKaply seemed to  
think he'd seen documentation that restrcting value excerpting to  
children only.

Options are the mfo processing instruction proposal, which I dislike  
because it adds a processing instruction into an element which should  
be about the semantics of the content, not ‘how to parse this’, we  
could restrict it to children only, which I suspect could break lots  
of hCards TEL fields, or perhaps the third option I've added today,  
which is to specify parsing children only as the default behaviour,  
but allow individual properties to override this to all descendants.  
Properties like TEL, where it's reasonable that it will be at the  
outer edge of a DOM tree, could permit all descendants to be parsed as  

Both excluding fields and parsing grandchildren add optionality to  
particular fields, from a parsing POV I see it as a set of switches  
when parsing each field, which can at least be clearly defined. Does  
that seem reasonable?

As always, feedback most welcome and requested!


More information about the microformats-dev mailing list