Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Thursday, July 23, 2009 2:56 PM
> To: XRI TC
> Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16
> 
> 
> On Jul 21, 2009, at 11:13 AM, Eran Hammer-Lahav wrote:
> 
> > We can also turn this into an attribute of <Subject>, something like
> > 'set="prefix"' which will allow other rules in the future (such as
> > 'set="regex"').
> 
> One problem with using a "set" attribute on <Subject> is that you are
> still limited to a type of xs:anyURI.  This would prevent you from
> having any kind of meaningful regex value down the road.  Granted,
> this isn't a problem for our current use-case, where set="beginswith"
> works just fine, but how much flexibility do we want to leave here?  A
> <SubjectSet> element with a type of xs:string provides a lot of
> flexibility with the value.  Breaking things back out into separate
> XML elements as Scott just asked about also provides flexibility, but
> in a different way.

The decision between an attribute or a new element is still open and this is one reason to opt for a separate <Subject> and <SubjectSet> elements. In a separate approach, the <SubjectSet> element can have a 'match' attribute which will only define 'beginswith' at this point. The content of this new element will be string.

I don't have a strong preference between the two. Others?

> One specific use case does come to mind with this discussion, also --
> webfinger.  From the last webfinger discussions I remember, the plan
> was still to use a non-URL identifier.  So either they would need a
> non-URL subject element to use for matching, or perhaps would need to
> define some other rules for matching the identifier with the <Subject>
> URL value?  This may not be anything we need to worry about for XRD,
> but I at least wanted to mention it.

I don't think this is a requirement for us. First, if it needs an element for an "email-like non-URL identifier", it can extend the schema. But there are other ways to go about it. For example, the protocol can simply "transform" these non-URL identifiers to URIs and continue from there.

EHL