On Feb 23, 2007, at 1:44 AM, Joe Andrieu wrote:
Ryan King wrote:
I understand this. I agree that this is a desirable goal. I would
personally like to see it happen. However, the simpler
problem of two
hcards representing the same person (or organization) should be
solved first, because it is a simpler problem, with a simpler
solution (which may not require adding any properties to hCard).
If all you want to do is have two hCards represent the same entity,
why not just use the same UID?
I think I understand that it is to traverse the network to discover
multiple, "synonymous" hCards for the same entity? That what you
want is not just synonymity, but discoverable synonymity. Is that
correct?
Yes. The nice thing about URLs is that you can dereference them and
consume the resource returned.
RFC2426 [1] (the vCard spec incorporated by reference into hCard)
specifies the URL type use as:
To specify a uniform resource locator associated with
the object that the vCard refers to.
Your algorithm was:
1. if no uid or uid == the uid from the previous
iteration/recursion => you're done
2. if url == uid and there's an hCard at that url,
recurse with the new hCard
In that case, what you are saying is that if the UID is the same as
the URL, one should expect to be able to assume a common
relationship between this hCard and any hCard with either no UID or
a matching UID at the URL for this hCard.
Here's what seems to fail in this usage:
1. Referrees without UID match any referring hCard
2. Ambiguous relation when multiple hCards are present at URL
3. UIDs that are XRIs and not URLs
4. UIDs that are not URLs, generally.
1. Referrees without UID match any referring hCard
If the referred to hCard has no UID, the algorithm assumes
"relatedness", but that seems dubious at best without a confirming
UID.
I agree. It is a bit dubious. This might be something that's left to
consuming applications to decide.
2. Ambiguous relation when multiple hCards are present at URL
If the referred to URL has multiple hCards, each with no UID, there
is no way to disambiguate which one(s) should be "related."
So... Refering card:
<span class="vcard">
<span class="fn">Mr. Andrieu</span>
<span class="uid url">http://www.andrieu.net</span>
</span>
While on Andrieu.net we might have multiple hCards
<span class="vcard">
<span class="fn">Joe Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Julia Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Mike Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Maureen Andrieu</span>
</span>
Who is "Mr. Andrieu"?
This is even more likely to occur when we accept the dynamic nature
of the web and the inevitable consistency errors of
less-than-perfect data maintenance. It seems to me that relating
only cards with common UIDs makes a lot of sense.
One option here would be to only take hCards in an <address>. Of
course that doesn't apply in your example, but it would work in some
real world examples (like http://theryanking.com/blog/).
3. UIDs that are XRIs and not URLs
With the use of OpenID as UID, do we extend the field URL to
include XRIs? This may or may not make sense, but stuffing an XRI
into
a URL/URI is out of spec unless the spec changes to allow it. XRIs
are designed to replace URIs, but plenty of consuming
applications break today if you try that.
4. UIDs that are not URLs
I stand by the argument that UIDs that are not URLs should be
viable in any mainstream use of any microformat. Your bias towards
URLs as UIDs shouldn't limit people's use of UIDs with alternate
formats, such as XRIs. If we feel strongly about such a bias, as a
community, we should change the hCard spec to require UIDs as
URLs. XRIs as UIDs is just /one/ example where I think the evidence
is overwhelmingly clear that there is technical acceptance and
solid reasoning for UIDs that are not URLs. Now, we could change the
definition of "URL" to include "XRIs", but I think we are better
off accepting that we cannot predict the future, nor should we
presume that URLs are the only good UID unless we are willing to
make that a requirement in the spec. And frankly, that would put
our definition of URL at odds with RFC for URLs.[2] The spec uses
"should" for good reason. It is because of that *should* that XRI
UIDs are 100% compliant with hCard /today/ without redefining the
spec. That's a good thing. Making URL UIDs a requirement for
discovering synonymous hCards seems arbitrarily limiting with
minimal payoff.
Items 1 & 2 could be trivially addressed by simply modifying your
algorithm to require that the UID of the /referred to/ hCard match
the UID of the referring hCard for anything to work. So they aren't
major issues. (And it is clear that in the brevity of your
algorithm, you didn't say termination assumed "relatedness", so 1&2
aren't all that important.)
However, non-URL UIDs, as exemplified by XRIs as UIDs is a
fundamental problem that you have not satisfactorily addressed
other than
by asserting
What better UID is there than a URL?
You also stated:
Indeed, in vcard UID is just a string, but my proposal is that we
make it by default a URL. It's a simple change (which may already be
implemented in X2V).
You're right, I think UIDs should be URIs, but they don't have to be.
I think the hCard spec should specify that UIDs be parsed as URLs,
but that doesn't mean you *must* use a URI. For example, this would
work just fine:
<span class='uid'>this is not a URI</span>
Just don't put the XRI in an [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED] or [EMAIL PROTECTED]
Your disposition is clearly yours, not what the spec reflects, and
you have yet to make a solid case for it, much less secured
community support for changing to that default. I referred to your
disposition as a religious belief not to insult you, but to
clarify that is an assertion of your presumptive belief. From your
arguments, I have nothing but your faith in URLs as UIDs, no
evidentiary arguments have been presented. If the core of your
argument is that UIDs are supposed to be URLs, that is a completely
different proposal than both this thread and the originating thread
(canonical hCards) is talking about.
You later stated:
Also I'm not saying that UID-as-URI is the "right" way to do things.
I'm just saying that it's the most useful way to do things."
For many applications, XRIs are arguably more useful. In fact, I
think XRIs answer your initial question adequately. They are a
better UID than a URL. Your simple assertion of your opinion is a
statement of belief, rather than a compelling argument. My
assertion that XRIs are better is also a statement of belief.
However, there are a lot of other smart people that also disagree on
this topic (in both directions). Debating it here would be off-
topic to say the least. However, the acceptance of the viability of
XRI by a significant community is itself sufficient challenge to
your blanket assertion of the "most usefulness" of URLs as UIDs.
Other UID schemes can be just as useful, perhaps more so.
XRIs may be theoretically more useful, but URIs work today in
existing implementations. Microformats in general are built upon
already-deployed technologies. That's why URIs (especially
dereferencable ones) are useful.
Because of that, I strongly feel that requiring UID=URL as the only
vehicle for discovering synonymous hCards is a huge mistake.
More importantly, requiring that UIDs be URLs is a proposal/debate
in, and of itself. It is currently sidetracking this discussion
of how we might relate (potentially authoritative) hCards to each
other.
I'm not saying UIDs must be URLs, I'm saying that they should be
parsed as such, which included fallback to non-url values.
Instead, I would like to propose that "source" be traversed to
discover synonymous hCards, relying on UIDs for association, without
requiring that source == UID prior to traversal.
[my apologies if my shifting position seems to undermine my case. I
have learned much discussing this topic and can see why
"via"/"via self" has problems and find "source" to be both in the
vCard spec and suitable for the usage.)
Again from the vCard RFC:
If the SOURCE type is present, then its value provides information
how to find the source for the vCard.
That seems like what we are looking for. It is not required to be
a URL, but it can be. If a consuming application does not know
how to resolve the source, then it has no way to continue the path
of discovery. That's both reasonable and expected.
Previously, you objected:
SOURCE is already used by X2V to indicate the URL at which the
current hCard is available. I don't think we'd be able to override
that at this point.
I respect the work done by Brian Suda and others on X2V, but this
argument doesn't pass the smell test.
First, I think "the URL at which the current hCard is available" is
exactly what we mean. If a consuming application sets the
source of the contact to where it found it, we have the "authority"
or "relatedness" we are talking about. If the consuming
application is savvy enough, it can follow any "source" it might
find on the page to discover additional information from other,
synonymous hCards.
I agree.
Second, I have a hard time believing that modifying the X2V XSLTs
to handle the clarified semantic is an unsolvable problem
/technically/. It may be hard for political reasons I don't
understand, but that is a different issue and I would argue that
shaping specifications based on politics is bad technology
development.
I didn't mean to suggest that it was a unsolvable technical problem,
but merely a problem of figuring out what the application should do
and make sure any changes don't break existing content.
Third, on principle, it seems incredibly arbitrary to make a case
for the spec based on any particular implementation. Just because
the <blink> and <marquee> tags were implemented in Netscape and IE,
respectively, didn't mean that HTML should adopt those
"innovations." Nor should HTML have been limited to table-based
layout just because no browsers had CSS before there was CSS. The
spec should evolve to provide the most coherent, consistent, and
usable foundation for the most compelling applications, it should
not arbitrarily be limited based on existing technology.
X2V can be changed. I'm not suggesting that we *don't* change things
because existing applications deal with them a certain way, but we
need to be very careful not to break existing applications. Perhaps
no one depends on the SOURCE returned by X2V. In that case, we can
change it rather freely, but, if people depend on it we need to be
careful.
And indeed, both of us are suggesting an incredibly minor change to
the extended semantics of a single field to support a particular
use case. URL and SOURCE will still mean basically the same thing
as always. However, an additional implied semantic would enable
discovery of synonymous cards. This seems like an odd item to limit
based on existing XSLT files.
So, I think uid+url could address problems 1&2 with a modified
algorithm (or perhaps just a clarified one: your algorithm terminated
on no uid, but you didn't say if that implied relatedness).
However, it does not seem capable of addressing non-URL UIDs such as
XRIs, which are acceptable forms of OpenIDs, which are now being
supported as widely by both AOL and Microsoft, two gorrillas who
are making their own cowpaths in this area. As discussed elsewhere
OpenIDs /are/ UIDs.
I understand that Microsoft and AOL will be supporting XRIs, however
we build microformats based on existing practice on the web. If their
support leads to people using XRIs, then it will be useful for us to
support.
(also, yes, we need to clarify my algorithm. I'm not sure what the
answer should be yet, let me think about it.)
In contrast, uid+source, without a requirement that source==uid
addresses all of the above shortcomings of uid+url, including all of
the use cases that uid+url supports, with no new fields added to
hCard.
So, could you outline in a concise form the fundamental problems
you have with uid+source for related hCards?
I don't see any problems other than figuring out what consuming
applications who convert to vCard should do with SOURCE.
-ryan
--
Ryan King
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
