Scott Reynen wrote: > On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote: > > As I understand it profile URIs are not required. > > > > If so, the parser cannot distinguish between wild semantic > HTML and an > > hCard. > > Profile URIs are not required for publishers, but parsers are > free to > ignore HTML without profile URIs, and I think it's reasonable to > expect them to start doing that if name conflict becomes more than a > hypothetical problem. This mirrors how natural language works. > Until there is some need for clarification, we assume everyone knows > what we mean. Then there is a need for clarification, we clarify. > No one goes around defining every word before they use it, and I > don't think we can expect publishers to behave differently with HTML > symbols. We could require profile URIs, but that won't make anyone > use them. OI think only a practical need for disambiguation will do > that.
Making people use them is not the same as clarifying in a spec what should be done, must be done, and what is optional. If we are specifying that parsers can ignore non-profiled semantic HTML that looks like microformats, we are essentially saying parsers can ignore non-profiled microformats, since you can't tell the difference. Which means that URI profiles are /effectively/ required if you want to be assured that standards-compliant parsers will pick them up your microformats. Yea! I think profiles are great. So, why not formalize the requirement? If authors write non-compliant code (without the profile), *GASP*--who would ever do that?--then they will have reason to understand why the parsers ignore it. Just like if they write non-compliant HTML, they can understand why it doesn't work. (Ahem, we'll ignore the issue of non-compliant browsers). However, without the profile requirement, authors have no reason to expect that parsers won't pick up their "standards-compliant" microformats. 100% compliant code should work with 100% compliant parsers. That seems self-evident. Does it make sense to allow compliant parsers to ignore compliant microformats? -j -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
