[uf-discuss] Scraping or parsing?

Tue Mar 6 03:16:27 PST 2007

Ryan Cannon wrote:
> > Ryan Cannon wrote: Adding an @profile attribute to he
> > <head>element is far less technically demanding than,
> > say, creating a tag space, which we also require.
> > Especially as the addition also has no performance or
> > usability impact.
> > 
> > It may be less technically demanding, but the latter is
> > needed.
> > 
> Creating a tag space allows a user of rel-tag to discover
> precisely what the author means by the text of the tag.
> Profile URIs help authors discover precisely what an
> attribute value means. In light of your later point about
> grokability, I think both are needed.

I'm not sure I follow. And reading your whole email, you may be talking
things different from what I'm talking about anyway.

> Although I'm not sure about the others, I know that RSS,
> CSS and XML were designed not simply for humans, but for
> humans with a specific set of skills in place. 
> People with these skills built tools that then fueled (or are
> fueling) wide-spread adoption. Perhaps I'm wrong, but I
> see microformats in the same vein. 

And fundamental to my arguments are that skills can be learned.

> I think your concept of "quick" and "widespread" are
> interesting as well--CSS 2 (Recommended 1998) and XML
> Namespaces (Recommended 2006) have roughly similar
> penetration in Web browsers (imperfect in most, quite
> poor in a major one).

I have a book in my hands "Definitive XML Schema" written in 2001, published
in 2002 and it discussed Namespaces in depth. The recommendation may have
been last year, but it was not last year that the technology was available
for people to use.

And the fact that the major browsers can incorporate technology is an
example of the Herculean effort from vested interests that I discussed. I
don't know any mere mortal content author who can get the logic of XML
Namespaces (after studying them on and off for six months, I gave up on
them, and I'll challenge anyone on this list to be able to author a valid
XML document that contains complex schema right without having to run
through validation to debug it first.)

> > Believing that there is or should be a difference
> > between "users" and "content authors" is either simply
> > ignorant or actively arrogant.
> > 
> To quote Andy Mabbett, this is a straw man. I never said
> this, nor did I intend it. 

I misunderstood, I thought you did. My apologizes if I got it wrong.

> What I said was: WYSIWYG-only
> users can't read code. Microformats without tools are
> code. In my experience, WYSIWYG users who post code they
> cannot read rarely get the outcome they desire. Authoring
> Microformats with the intention that they be usable *as
> code* to content authors *who cannot read code* is a pipe
> dream.

Help me with this...  How do I recognized these "WYSIWYG-only users?"  Are
they a certain color?  Height?  Or maybe they have barcodes on the back of
their necks?  Or can I just give them IQ tests to determine who they are?

Clearly my sarcasm drips... The point I'm making is that "WYSIWYG-only
users" exist because technologist think it is okay to implement technology
that is complex and *requires* tools as opposed to first implementing
technologies that humans can deal with and THEN designing the tools.

> > And if you'll forgive the tinge of melodrama
> > 
> I don't think it's appropriate, warranted or necessary.

But I did.

> This thread is about the necessity of profile URIs. I
> think the problems started with Scott Reynen's
> assertion[1] that:
> 
> > Profiles are not intended to work as parsing templates.
> > They just  identify the type of data so parsers can
> > figure out whether or not  it's something they know
> > how to parse.
> > 
> Profiles are intended for machines *and humans*[2].
> Providing profile URIs adds important disambiguation for
> the definitions of terms and helps content authors better
> understand the code they are writing. For example, say an
> author unfamiliar with hCard attempted to duplicate the
> following code:
> 
> <div class="vcard" id="banana"> <p> <a
> href="http://ryancannon.com/" class="fn url bar">Ryan
> Cannon</a> is a <span
> class="constellation">Scorpio</span>. </p> </div>
> 
> What is necessary? What is significant? Why banana?
> Instead of having to wade through the vCard or hCard
> spec, the profile provides an easy-to-read description of
> the format and its included terms. By allowing
> microformat publishers to omit profile URIs, you also
> eliminate important clues as to what microformats mean,
> what is important, and what is not. *That* is a good way
> to keep content authors from becoming anointed.

This is where I think we veered off course.  It *sounds* like you are
thinking that I was opposing a method to disambiguate. If so, you
misunderstood completely.  Hell, I screamed about the need for
disambiguation a while back but most people here said it wasn't an issue to
be concerned about, so I gave up on and quit actively monitoring this list.

No, what I was saying was that there ALSO needs to be a way for someone who
is a content author to disambiguate a microformat WITHIN the <body> IN
ADDITION TO and as an alternate for using @profile in the <head>.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away
attempts to improve the web..."