[uf-discuss] Extended types (as in VCard, chapter 3.8)

[Tobias Prinz]

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-salary">50000</span>, because where is the difference to <span class="printMeGreen">Green 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