Re: Design Principles

Kornel On 09-05-26 16.06:
> On 26 May 2009, at 12:18, Anne van Kesteren wrote:
>>
>>> 2.4. Pave the Cowpaths
>>>     = this to me also supports building on existing profile related
>>> authoring practises such as microformats. Or is it only those
>>> microformatters that do /not/ use @profile that represent a cowpath?
>>
>> While microformats claim to need a profile attribute in practice they 
>> do not use it I believe for consuming etc.

The microformats points to  /HTML 4/ which says that one can establish 
profile page URIs and  link to them via @profile. The HTML 4 spec here 
presents /more/ than a mere attribute specification, it presents a "sub 
specification system". Where is the "claim" in this?

Do you suggest that authors establish profile pages for describing meta 
data profiles, but that actually /using/ these URIs in order to inform 
what conventions that are being followed  should be prohibited? This 
seems very contrary to what the Web is about.

So the question is still /what/ in this is it that represents a cow path? 

    * HTML 4 /has/ a method for defining meta data profiles:  A single
      web page that represents the profile. Do we need to change that
      cowpath?
    * HTML 4 say that applies a URI, the most common cowpath of all, for
      pointing to the profile that is being used. Do we need another
      cowpath than a URI?
    * When you describe how some _User Agents_ do not use the URI for
      anything, then I think you are stretching the cowpath concept,
      cowpaths do not pertain to what User Agents do.


> Indeed. When developing hCard validator (conformance checker) I've 
> noticed that few pages use profile attribute, and there are no hCard 
> processors that use it, so I haven't made that a requirement. I'm even 
> tempted to remove all warnings about it.

If your validator wasn't a specialised hCard validator, you could have 
used 'hCard' as CURIE for 'http://microformats.org/wiki/hcard-profile', 
internally. ;-)  **

> I've also found pages that use wrong profile — most often XFN. As far 
> as I understand that would mean that hCards should not be processed on 
> such page, and profile support in that case would be harmful.

I saw that your validator page uses the profile 
"http://www.w3.org/2006/03/hcard". We can at least say that /that/ hCard 
profile "licenses RDF data extracted by hcard2rdf.xsl from the 2006 
vCard/RDF work."

> I haven't implemented "proper" XMDP support. The goal of these 
> profiles is unclear to me, because AFAIK they're not namespace URIs, 
> but were supposed to be some kind of DTDs. However amount of 
> machine-readable information in XMDP is miniscule (list of names only) 
> and practically useless for Microformats parsing.
-- 
leif halvard silli

Received on Tuesday, 26 May 2009 21:57:34 UTC