Hello there!
Thanks for answering my last question concerning rfc2397 and embedded images.
My code now works beautifully using the recommended methods.
Of course I got myself another nice question, and that one concerns extended
types, which means freely defined elements of an hCard. Example: I have got a
field salary which I want to embed into my hCard.
VCard recommends (Problem here: As I read it, it does not say requires) to
prefix them with X- and that's it, so I'd go with X-SALARY there. This possible
for a simple reason: A VCard does only contain VCard information, so all those
additional fields are VCard fields anyway.
I have not found a note on that in hCard, and I understand why:
With hCard, the assumption of having only hCard data within does not hold. I
cannot simply add span class=x-salary5/span, because where is the
difference to span class=printMeGreenGreen text/span from a lexer's point
of view?
I only see three potential solutions here:
1. Everything that is listed with a class within a hCard element is a
(potential) additional type. Depending on the document size and the amount of
markup used there, that might amount to loads of data.
2. Everything within a vCard-element that has a class matching /^x-/ is an
extended type. This changes the recommendation within VCard to a requirement.
A reasonable one, but even now I have trouble explaining to the CTO why our own
data cannot have our company's nice prefix but needs to start with x-. I
ventured to rename the company, but he's not into that. Still, it would seem to
be the most sensible solution.
3. Not work with extended types at all. Which makes it unattractive to all
systems that want to use hCard as a basic system to exchange data but want to
extend it. It also is not in the spirit of VCard, I'd say.
And yes, this is an actual problem I encountered, not just a theoretical
exercise to find limitations of hCard.
I am currently trying to exchange extended contact data and I need to retrieve
that data from the parser (well, I could do a second parse with my own parser
to retrieve additional data, but where's the point?). So I might be willing to
use a work-around and (ab)use another element to store those values. I was just
wondering which element would make the most sense?
It would need to be an element that has a type (to hold the real attribute
name), that can appear more than once and that, ideally, has a very broad
meaning. What would you use?
Thanks in advance,
Tobias Prinz
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
