[microformats-discuss] URIs please!

[Ryan King]

On Jul 14, 2005, at 8:45 PM, Peter Janes wrote:
> Kevin Marks wrote:
> [...]
>> Right, Peter, but there is a difference between an elemental  
>> format , which defines a single value, and a compound format like  
>> hCard.
>
> As far as I can tell the main difference is what the context is.

Actually, I think the elemental vs. compound is more about size and  
reusability than anything else. I think Kevin came up with that  
distinction, so he'd be able to answer more clearly.

>   For elemental formats the context is the entire document; for  
> compound documents it's the content of all elements that match a  
> top-level element in the XMDP hierarchy.

I think you're reading too much into the elemental vs. compound  
thing. Elemental microformats are "small and useful for building  
other microformats." Compound are "bigger and sometimes composed of  
elemental microformats."

> There's nothing stopping an elemental format--where all occurrences  
> of its attribute values on a page are significant--from having an  
> XMDP that defines its meaning.  (In fact, it's encouraged that all  
> microformats have XMDPs, whether they're elemental or not.)

Right. And no one is discouraging use from doing that.

>   That means that elemental formats are the counterexample to the  
> statement that, on a page referencing an XMDP profile, individual  
> attribute values are meaningless unless they're contained by some  
> other particular attribute value (which is how I read "we're not  
> looking for individual attribute values, we're looking for  
> attribute values in context").

No. I think you've misunderstood what I wrote. I was trying to  
emphasize context as a way to disambiguate terms. "Context" does not  
imply "containment."


> I'd propose a new version of Bud Gibson's statement 2, on what  
> linking to an XMDP means:
>
> The presence of a link to an XMDP means that any occurrence of a  
> *top-level* attribute value defined in the XMDP is to be  
> interpreted according to the XMDP's definition.  Within that  
> context, any occurrence of an attribute value defined below that  
> top-level attribute in the XMDP's hierarchy is also to be  
> interpreted according to the XMDP's definition.

I really don't think it has to be this complex.

Why can't we just use the definiton of 'profile' from HTML [http:// 
www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.3]? That was the  
original intent with having profile urls. I don't think there's any  
value in diverging from that definition (of course, we are extending  
it in that we use profiles to define things outside <meta>).

>> Validating the existence of an elemental format is easy, as it is  
>> a single value; validating a more complex structure requires parsing.
>> http://www.microformats.org/wiki/elemental-microformat
>
> I'm not sure "elemental" means "defines a single value".

It doesn't. I just means "small and reusable."

> On that page only the Rel* microformats define single values;  
> VoteLinks, XFN and XOXO define many values yet are also considered  
> to be elemental.

Single value, multiple *possible values.* With XFN, you're looking  
for single values (scalars, if you will).

XOXO, of course, isn't very "small," but is heavy on "reusable." :)

> The distinction seems to be more one of structure: elemental  
> formats define values that are applied to an attribute of a single  
> element, while compound formats define values that are applied to  
> the attributes in a hierarchy of elements.  (robots-exclusion,  
> then, would be an elemental format.)

The distinction is not that clear, nor does it need to be.

>> Also, note the composability of the elements; you can make sense  
>> of rel="tag" within another format, even if you don't necessarily  
>> parse that format fully.
>
> Unless, for some reason, another XMDP is being used that defines  
> rel="tag" to have a different meaning.  One would hope that  
> microformats.org will be able to avoid any internal overlap,

Yes.

> but there's sure to be some group with their own format that  
> redefines an attribute value to something more specific to their  
> purpose.  Suppose the IETF defined a "references microformat" for  
> RFCs that used rel="tag" to refer to documents created by the W3C's  
> Technical Architecture Group;

Hmm. IETF an W3C working together? Sounds like a conspiracy. Of  
course IETF publishes all their docs in plain text, not HTML.

> now your tag parser's going to eat a lot of bogus data because it  
> presumes it knows what rel="tag" means.

Right.

>   Which gets back to the request that started this thread: to  
> explicitly identify each microformat used in a document by its URI.

Ok. That's enough.

We have consensus.

There is no disagreement.

We need to have URLs to identify microformats.

-ryan


> Sorry if this has rambled somewhat between topics; while writing  
> I've been skipping through the list and various websites looking  
> for references and examples to cite.  Feel free to divide and  
> conquer as necessary. :)
>
> Peter J.