Toby A Inkster schrieb:
Gordon wrote:
I second Andy Mabbet's concern about allowing multiple instances for
fields like e.g. country not making sense.
RFC 2426 says, 'Where it makes semantic sense, individual text
components can include multiple text values (e.g., a "street"
component with multiple lines) separated by the COMMA character (ASCII
decimal 44).' It doesn't specify which fields it makes sense for, and
which it does not — that is left to the judgement of the vCard
producers and consumers.
Here's an example with multiple countries, which makes sense:
<div class="adr">
<span class="extended-address">The Scottish Parliament</span>,
<br>
<span class="locality">Edinburgh</span>, <br>
<span class="postal-code">EH99 1SP</span>, <br>
<span class="country-name">Scotland</span>, <br>
<span class="country-name">United Kingdom</span>
</div>
Other countries that lie within the United Kingdom include England and
Wales, and some might argue Northern Ireland and perhaps even
Cornwall. The concept of countries within countries could also be
applied to the United Arab Emirates, and Bosnia and Herzegovina, but
not to say, Australia or the United States where although the member
states enjoy similar levels of autonomy, few would seriously describe
them as countries.
In one of my earlier drafts for this diagram, I had implemented
givenName and familyName as multiple. I am not sure why I did this and
cannot find proper reference in the RFC. Can these be multiple?
Similar situation. I can't think of any reason for including multiple
given-names and family-names in a vCard, but perhaps it might be
common in some other cultures — I don't know. Still, there's no harm
in supporting multiple instances. The hCard spec says multiple
instances are allowed.
Can geo be multiple?
Not according to the hCard spec. The RFC isn't particularly explicit.
My parser supports multiple geos within a vCard. But that's just me
being lazy — easier to pull them all into an array than to choose one
to keep.
It is listed with the singular properties, but if geo is meant to
reference a place, shouldn't geo be part of the Address it references?
I can't imagine that many parsers would have a problem with geo being
nested within the address, but in vCard terms its a separate property,
so once parsed, should be represented separately from the address.
> http://lib.omnia-computing.de/images/JCard.png
You have "n" as being "0..*". Each hCard should have exactly one "n"
property, Though it may be implied rather than explicit, and it may be
empty in the case of hCards for organisations.
Thanks Toby. I have updated the zip file and the diagram now.
One more thing: I am unsure about the plural naming convention I suggested.
Apart from indicating if the value of a property can hold multiple
values, I don't see any added benefit right now. But I do see an
unnecessary level of complexity when it comes to parsing an hCard into a
jCard. You would need to know how to properly inflect a property, e.g.
you cannot simply add an s to "honorific-prefix". And whats the plural
of adr anyway? Same for converting plurals back into singulars. And
since we want to represent an hCard anyway, why should we deviate from
the property names of an hCard, if it's not adding any worthwhile
benefit. So, back to singular?
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
