OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Host Meta and XRD, POWDER (ISSUE-36 ,siteData-36)

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On
> Behalf Of Dan Connolly
> Sent: Monday, December 07, 2009 9:52 AM
> To: www-tag@w3.org
> Subject: Host Meta and XRD, POWDER (ISSUE-36 ,siteData-36)
> "3. The host-meta Document Format
>    The host-meta document uses the XRD 1.0 document format as defined by
>    [OASIS.XRD-1.0], which provides a simple and extensible XML-based
>    schema for describing resources."
>  -- http://tools.ietf.org/html/draft-hammer-hostmeta-04
> This pretty clearly overlaps with POWDER. I wonder why it wasn't caught at
> CR or even much earlier.
> Did the W3C POWDER WG neglect to engage a relevant part of the
> community?

I am not aware of any official engagement or outreach, but Phil Archer and I have been in touch discussing linking to descriptors and discovery since November 2008. Both communities have been aware of one another.

It important to understand how host-meta came to be [1], evolving from site-meta which included its own XML schema, then a text-based host-meta document, then replaced with /.well-known URI prefix with registry, and then reintroduced with a different use case (shared document for simple host-wide metadata) as host-meta. We now have two separate proposals, /.well-known and host-meta. Host-meta only recently adopted XRD as its document format and that has nothing to do with the Well-Known URI proposal.

> Is a significant community producing things like site copyright policies with POWDER?
> If so, and Host-Meta with XRD gets deployed, then consumers will have to support both formats.

If a protocol for copyright policies uses POWDER as its descriptor format but uses host-meta for locating that information, then yes. But this seems like a bad way to design protocols. If the copyright policy requires a rich schema or its own anthology, POWDER would be a good candidate as XRD would require either a lot of extension work or a flat list of key/value properties. On the other hand, if all you need can be expressed with a simple link or key/value pair (and you don't have too many of those), and apply to the entire host, host-meta would be the easiest solution.

Once you are in the business of defining your own schema or anthology, you might as well register your own well-known location document in the proposed registry, as host-meta will only add a layer of indirection without any benefit. Just say: copyright policy is expressed using the POWDER format, X anthology, and is located at http://example.com/.well-known/copyright.

However, a client looking to implement both such a copyright policy protocol as well as say, WebFinger  or OpenID (as proposed for future versions), will have to understand both. But I am not sure what's the argument against that.

> That seems like a pretty clear standardization failure.

XRD and POWDER represent completely different *unbridgeable* approaches to providing resource descriptors.

POWDER builds on the richness of RDF and subject-matter anthologies providing a descriptor format that can describe resources as well as resource-sets and other groups. It cannot be considered a simple specification (actually, a set of specifications). XRD takes an opposite approach, offering a bare-bone schema with extensibility that is largely based on link relations and key/value properties, focusing on describing a single resource identified by a URI (though host-meta is an exception). The XRI TC has literally spent the past year trimming XRD down to only the most basic subset required.

XRD is optimized for rapid adoption among the communities supporting its development (OpenID, WebFinger, OAuth, Portable Contacts, etc.). To these communities, POWDER is a non-starter simply because of its complexity (perceived or not). It is also important to note that XRD was developed because XRDS (and its simpler profile XRDS-Simple) was deemed too complicated. Replacing XRDS with POWDER wouldn't interest anyone I know in the XRDS community.

This is not a criticism of POWDER, though I can see how some people would consider it as such. The relationship between POWDER and XRD is very similar to that of SAML and OAuth. They greatly overlap but the complexity of one made it appealing to develop the other, while at the same time, not trying to replace it or compete with it.

In other words, it's a cultural thing.

I also want to point out that both POWDER and XRD are very young and still need to prove their value. Given how early we are in the development of resource descriptors, a bit of "competition" is a good thing. Trying to force either effort to use the other would be a  clear standardization failure.


[1] http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]