Value excerpting - thoughts and random observations

I've been noodling with value excerpting recently, as
Cognition's  
support for it has been limited until recently -- it was
only  
supported for .vcard .tel, .vcard .email and .vcard .impp,
but I  
realised that I really needed it for .vfreebusy .freebusy
and so  
decided to generalise it to pretty much all properties.

Here are some interesting observations:

	<span class="fn n">
		<span
class="given-name">Toby</span>
		<span class="additional-name"><span
class="value">A</span>.</span>
		<span
class="family-name">Inkster</span>
	</span>

Value excerpting here is used so that the dot displayed
after the  
middle initial isn't taken to be part of the
additional-name, yet it  
displayed as part of the formatted name. Unintentional
consequence:  
FN is parsed as simply "A". I've not tested other
parsers, but I  
assume that the results are similar. Of course, a better way
of  
marking it up would have been:

	<span class="fn n">
		<span
class="given-name">Toby</span>
		<span
class="additional-name">A</span>.
		<span
class="family-name">Inkster</span>
	</span>

Not using value excerpting at all.

Consider <abbr> versus "value":

	<span class="fn"><abbr title="Toby
A. Inkster"><span  
class="value">Foo</span></abbr><
/span>

FIGHT!

Under my interpretation, FN is "Toby A. Inkster".
The span with class  
"value" is ignored, as it is the child of an
<abbr> with a non-empty  
title attribute.

Yet <abbr> versus "value" can be used for
good as well as evil.  
Consider this:

	<span class="dtstart">
		1 October 2008
		<abbr class="value hyper"
title="20081001"></abbr>
	</span>

With the CSS abbr.hyper{display:none;}.

This uses existing microformats patterns (value excerpting,
abbr  
pattern) to create a more accessible alternative to the
abbr/datetime  
pattern. Because it uses existing patterns, it should work
in  
existing tools. *Should*, not necessarily *does*! Works in
my current  
unreleased version of Cognition. (Which I'll be releasing as
soon as  
the RDFa group get around to updating their syntax document
with  
their recently decided changes.)

Another thought: what to do about this?

	<span class="fn">
		Foo
		<span class="value">
			Bar
			<span class="value">
				Toby A Inkster
			</span>
		</span>
	</span>

Should the FN be:

	"Bar Toby A Inkster"
		Ignoring the inner class="value".

	"Bar Toby A Inkster Toby A Inkster"
		Parsing both values and concatenating them, as if they
were not  
nested. Cognition currently does this.

	"Toby A Inkster"
		The outer "value" itself is subjected to value
excerpting.

Or do we simply say that the parsing of such a construct is 

undefined, so authors must not use it? And then let parsers
handle it  
however they like, reasonably confident that they will never
run into  
such a construct.

-- 
Toby A Inkster
<mailto:mailtobyinkster.co.uk>
<http://tobyinkster.co.uk
>



_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

2008/4/16, Toby A Inkster <mailtobyinkster.co.uk>:
>  Consider <abbr> versus "value":
>
>         <span class="fn"><abbr
title="Toby A. Inkster"><span
>
class="value">Foo</span></abbr><
/span>
>
>  Under my interpretation, FN is "Toby A.
Inkster". The span with class
> "value" is ignored, as it is the child of an
<abbr> with a non-empty title
> attribute.

--- child elements of microformatted data are not
"looked into", so
because the FN value is on a span, it looks at the node
value. In this
case, there is also a VALUE, but in this case they are the
same value
"Foo".

So in that example FN==Foo, the abbr does not play any role
in the
parsing because it does not have any explicit microformats
classes.

>  Yet <abbr> versus "value" can be used
for good as well as evil. Consider
> this:
>
>         <span class="dtstart">
>                 1 October 2008
>                 <abbr class="value hyper"
title="20081001"></abbr>
>         </span>
>
>  With the CSS abbr.hyper{display:none;}.

--- this would be a correct use of both abbr and value (it
is not a
versus in this instance). The parse would normally find the
class
DTSTART and find that it is on a span, so it should take
the
node-value. This node value happens to have a child with a
class of
VALUE. That parser then looks to that node to see if there
are any
additional semantics. In this case, it is an ABBR so the
title is
extracted.

While this is valid for parsers, TIDY and other tools strip
out empty elements.

>  Another thought: what to do about this?
>
>         <span class="fn">
>                 Foo
>                 <span class="value">
>                         Bar
>                         <span
class="value">
>                                 Toby A Inkster
>                         </span>
>                 </span>
>         </span>
>
>  Or do we simply say that the parsing of such a
construct is undefined, so
> authors must not use it? And then let parsers handle it
however they like,
> reasonably confident that they will never run into such
a construct.

--- to my knowledge, this is currently undefined. My
interpretation would be

FN: Bar Toby A InksterToby A Inkster

It would find the first VALUE "Bar Toby A Inkster"
and concatenate it
with the second "Toby A Inkster" (without spaces
inbetween)

Anyone wishing to continue the discussion of parsing rules,
this
should be done on the dev-list.

-brian


-- 
brian suda
http://suda.co.uk
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss