Re: a common understanding of profiles

Just wanted to clarify a few pieces for you.


> Indieweb overloads your homepage as an indirect identifier for a person.
> The mandatory (only?) serialization is HTML.  The first h-card tag in the
> document is person.
>

The first h-* is considered the representative object of the URL.
https://ben.thatmustbe.me/ has an h-card class on the body, so that URL
should be treated as a card.  Generally people just look for the first
h-card however when they are given the URL as a person's identity (logged
in from that URL).

It seems to me that the u-url attribute is very valuable here, because it
> allows an indieweb h-card to have a URI.  At this time the indieweb parsers
> dont notice this, but there's no reason why that might not happen in
> future, if there was a need.  So I see a possible path to convergence on
> that front.
>

Microformats parsers do return the URL, that is what should be the
canonical url for the person, but again, since most people are given the
URL in the context of a person's account, they will not follow this path,
they really should.

One of the best points we brought up in chat is that the microformats
parsing algorithm talks about parsing a document, not a URL.  That means if
I use a fragment in the URL, its perfectly reasonable to say the receiver
should be pulling that specific ID (if found) and feeding only that part to
the parser.  That means if I had an h-feed first, then h-card with an
id=me, then it would be perfectly acceptable to say that ....com/#me is the
URL for that h-card.

The problem is again that most parser implementations ignore this fact and
(in an effort to make things simpler) allow a user to just pass in a URL to
the parser library, which only does a CURL of the page, not that extra step
to parse for the fragment.