[uf-discuss] hReview for Stocks

John Panzer jpanzer at aol.net
Wed Feb 1 14:27:36 PST 2006


Tantek Çelik wrote on 2/1/2006, 12:25 PM:

 > On 2/1/06 12:04 PM, "Sujata Ramchandran" <sramchandran at aol.com> wrote:
...
 > > I have been asked
 > > to provide some additional fields within hReview
 >
 > Who has asked you for this?  That might help understand what the
 > problem is
 > that you are solving.

I should note that Sujata and I work together at AOL, and this is an 
outgrowth of the query I sent on 1/18 entitled "hReview on stocks" which 
  motivated the addition to the hReview FAQ regarding stocks and companies.

The motivating example is: 
http://journals.aol.com/hilaryonstocks/hilaryonstocks

For example:

   Exxon Mobil (NYSE: XOM): In This Case, Bigger Really Is Better

   When talking about big companies, they don’t get much bigger than
   Exxon Mobil. This company is a monster, in terms of revenues, earnings
   and market cap blah blah blah...

Note that the first line is a title which at least currently doesn't 
allow markup, and the stock ticker symbol is actually nowhere mentioned 
in the body which does allow markup.  So there's a dissonance here 
between what the writer wants to display and what we want to be able to 
automatically extract. One goal is to ensure that the human readable 
content is able to remain the same as today.

I think everyone agrees this is a review (right?), but there's a 
question about what's being reviewed (the company or its stock); of 
course this is a blog about stock picks which suggests the latter.  If 
this were a VC blog it might suggest the former.  In either case, 
though, we'd like to be able to mark up the ticker symbol in some 
semantic way, and that's the primary goal of this query.

 > > Here's what I am suggesting based on the parameters that I have been
 > given.
 >
 > Could you provide the parameters that you have been given?

One issue we're grappling with is that it's difficult for us to get a 
concrete set of requirements which don't amount to 'provide exactly what 
our undocumented proprietary API needs'.  So please bear with us as we 
try to evangelize microformats.

 > > <div class="hreview">
 > > <span class="item ticker" title="TWX"/>
 > > <span class="item exchange" title="NYSE"/>
 > > <span class="item country" title="USA"/>
 > > <span class="item expiration" title="20050518T2300-0700"/>
 >
 >
 > There are a few microformat and hReview fundamentals being violated here.
 >
 > 1. Visible data.  The ticker symbol, exchange, country should be
 > visible in
 > the text as the reviwer would write them.

We're not happy about this either.  We may not have a choice to start with.

 >
 > 2. Use XHTML 1.0 following Appendix C - Compatibility.  Empty <span/>
 > elements are not compatible XHTML 1.0.

I'm a little confused; it certainly seems to be valid XHTML 1.0 Strict 
according to http://validator.w3.org/check.  Do you mean that it may 
cause problems when served as text/html to some browsers?  Sure, but 
when just discussing a microformat I don't think that's relevant, is it?

 >
 > 3. There may only be one "item" per "hreview".  I thought this would be
 > obvious from the spec, but it apparently isn't, and it should be made
 > explicit.  I have added this as an issue to hreview-issues:
 >
 > http://microformats.org/wiki/hreview-issues

That's a really good point.  There's only one logical item of course, 
but how to extend hCard to handle additional types of item annotations 
isn't clear from the spec or FAQ.  Something to add?

So this is presumably acceptable:

<a class="item fn" href="...">Time Warner, Inc.</a>

But doesn't lend itself to automatic parsing of the stock symbol, which 
is a primary goal.  Would this be acceptable as a structured "fn"?

<a class="item fn" href="..."><abbr title="NYSE:TWX">Time Warner, 
Inc.</abbr></a>

...in which case, perhaps what we really need is a new nanoformat:

<a class="item fn" href="..."><abbr class="ticker" title="NYSE:TWX">Time 
Warner, Inc.</abbr></a>

...though semantically I think this is a bit dubious.  Also, it doesn't 
extend very well to additional values/attributes.  Thoughts?

I think Sujata needs to do more research on the "expiration" business. 
It's not at all clear to me if this is something of general use or 
something specific to this one application.  (E.g., one could imagine an 
hReview extension saying that a review should only be considered valid 
for a month, and treated as historical data thereafter.  Not sure how 
widely applicable this is, nor whether this is really the semantics that 
are desired by our customers.)

-- 
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer




More information about the microformats-discuss mailing list