hCard updated (was Re: [microformats-discuss] Pure JavaScript Greasemonkey hCard parser)

[Tantek Ç elik]

On 9/15/05 6:04 PM, "Mark Pilgrim" <pilgrim at gmail.com> wrote:

> On 9/15/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:
>>> The parser passes all of these tests:
>>> http://diveintomark.org/projects/greasemonkey/hcard/tests/
>> 
>> Super.  I presume these are all from hcard-examples[1]?
> 
> Indeed.  I fixed a few bugs in the examples on the wiki.

I saw that.  Thanks!

> I made a few
> other changes in my own test cases to keep myself sane.  For example,
> there is a wide acceptable variation in vCard attributes (type,
> encoding, value).

Yes.

> The examples in RFC 2426 are not in any way
> "normalized" (type values are sometimes uppercase, sometimes
> lowercase;

Do you want to suggest a particular normalization?  My bias would be to go
for lowercase normalization for enumerated values.

> N values are missing due to apparent spec bugs that hCard
> handles by making explicit the rules about "implicit N optimization";

Correct.


> etc).  I had to do some normalizing in my test cases, but I believe
> the results that the parser outputs are semantically equivalent to the
> examples in RFC 2426.

>From the examples/testcases that I looked at, yes.


>> Mark (and all other hCard developers), one quick question (maybe two), did
>> you have a chance to review the issues raised[2] in hcard-parsing[3][4] and
>> referenced in hcard-examples, and do you have any objections to the proposed
>> resolutions?
> 
> My parser handles both singular and plural forms of
> category/categories, additional-name/additional-names,
> honorific-prefix/honorific-prefixes,
> honorific-suffix/honorific-suffixes, and nickname (issue 1).  It also
> handles several forms of value properties which I believe cover all
> the possibilities raised in issue 2:
> 
> - title attribute
> - class="value" in child node
> - <pre> as child node
> - text content
> 
> So I don't really care which way the issues get resolved. :)

Very well then.

I have resolved the issues per the proposals.

In summary: 
  1. singular property names. When re-using names from another specification
(like an RFC), plural property names will be converted to their singular
equivalents, and multiple instances of those singular equivalents will be
allowed to capture the semantic of the plural properties.
  2. class="type". use of class="type" rather than enumerated type values as
class names
  3. class="value". addition of optional class="value" to subset how much an
element's node value is part of the property value.
  4. explicit notation of white-space preserving of <pre> and <br> (I
thought I already noted this but apparently not).

The following wiki pages have been updated accordingly:

 http://microformats.org/wiki/hcard
 http://microformats.org/wiki/hcard-parsing
 http://microformats.org/wiki/hcard-examples
 http://microformats.org/wiki/hcard-profile

Let me know if you find anything in those documents that contradicts those
resolutions.

Other than that, I consider hCard to be fully specified and complete and I'm
making the hcard-parsing document normative.

Please let me know if you find any additional issues or problems.

Thanks,

Tantek