[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-09
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 09 July 2009 USA Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) ATTENDING Will Norris Markus Sabadello George Fletcher Scott Cantor Nika Jones Joseph Holsten John Bradley Nat Sakimura AGENDA 1) CHOOSE NOTE TAKER Will volunteered to take notes 2) XRD 1.0 - LINK PROCESSING RULES Will summarized the two approaches being discussed in the following thread from the list: http://lists.oasis-open.org/archives/xri/200907/msg00063.html George stated that he basically interpreted the two arguments as "depth-first" traversal (what Drummond referred to as "link priority order model") vs "breadth-first" (what has been otherwise called the "flat model"). Will concurred, but clarified that the link priority order wasn't necessarily depth first. It could actually be either, depending on how the priority is specified. John said that priorities should be applied within the context of links having the same rel value. But what if the linked resources are related, but don't actually have the same rel value? For example, what if one linked resource has a generic "openid provider" relationship and another has a more specific "openid 1.1 provider" relationship? It was suggested that the previous statement be broadened to say that priorities should be applied within the context of "selected links", however those links happened to be selected. Will pointed out that the language in the spec already includes some provision for this, but stating that multiple selections should be done. From section 3.3: > For example, if an application is looking for all image resources, > giving higher preference to the JPEG formats over PNG, it will > perform two selection processes, one for each media-type, and assign > the resources in the JPEG set a higher preference value. Will mentioned that one argument in favor of breadth-first selection is to think of LRDD. Even though LRDD itself doesn't specify what order the three methods should be used, for XRD it's been suggested to start specific and work out from there. So you would first look for a <link> element in the body of the content, then the HTTP Link header, and finally the host-meta document. The preserves the idea that the most specific authority should have precedence (ie, the "owner" of the document over the "owner" of the domain). John added that this is true unless there is reason to believe that the content of the resource cannot be trusted, in which case you may want to use a different order. Applying the same logic, Will said that it made sense for linked resources in the first XRD to have precedence over any linked resources in linked XRDs, regardless of priority. There was then discussion about "including" an external document vs pointing to an alternate descriptor that can be used for the same resource. Scott questioned whether XRD linking within an XRD should be done in the same way as from an HTTP header. Should the rel values, or even the mechanism, be the same? While the semantics are the same -- the idea of finding a related resource, the actually meaning of the linking may be different. For example, if XRD linked from another XRD MUST be fetched and included into the first document in order to properly understand the descriptor, then that is something very different and likely warrants a new XML element. He mentioned XInclude as a similar example. George agreed that including another XRD is significantly different to a linked resource with a relationship of "describedby". Joseph added that the existing semantics of "describedby" as defined by POWDER would indicate that having a bunch of "describedby" resources should be unioned. Scott's interpretation of Eran's email was that this should all be outside of the spec. The processing rules should be left for profiles of XRD. Joseph mentioned the efforts that were made in RDF and didn't really work. Scott agreed, saying that we can try and do a whole lot of work, and still end up in the same place (profiles having to define processing rules). Selecting links is something that should be part of the XRD processing model, but FOLLOWING them is not. Put another way, selecting services is part of the core processing model, but USING them is not. Scott clarified that he is not suggesting that processing rules for linked XRDs shouldn't necessarily be a part of the initial deliverable, it's just a question of structuring the spec. If we need to define specific rel value for XInclude, we can do that, but it should be done in a separate section, if not a separate document. Will agreed, saying that he felt this was more or less the same problem as having multiple HTTP Link headers that point to separate XRD documents for the same resource. LRDD itself does not specify how to handle that, instead saying that it will need to be application specific. Whatever rules are devised for handling multiple XRDs in this case will likely help guide what applications should do when they discover a linked XRD from within an XRD document. Scott summarized his opinion that we need to define enough in the core specification to allow some individuals to go build useful profiles of XRD. He doesn't expect people to build actually useful code without that intermediary work. There will certainly be enough in the core spec for people to build code against (XRD Signature, etc), but applications will certainly need additional profiles to be useful. 3) OTHER XRD 1.0 ISSUES Will asked for a quick reading of how people felt about moving the Signature element to the bottom of the document. He and Scott and talked about it briefly off-list, and there was question as to whether SAX parser might care. Will asked if anyone familiar with SAX (specifically Markus and Nika) was aware of this being a problem. Nika didn't imagine there would be any problem, since they would have to parse the entire document anyway in order to build the canonicalized document used for the XRD Signature. Scott clarified that they might want it higher in the document because if the parser knows ahead of time that the document isn't signed, they don't need to worry about c14n. No one seemed to think this was a very big concern. 4) LRDD - SUBJECT OF A HOST-META XRD see: http://lists.oasis-open.org/archives/xri/200907/msg00068.html 5) OTHER LINK HEADER/HOST META/LRDD STATUS/ISSUES see: http://lists.oasis-open.org/archives/xri/200907/msg00068.html 6) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES Drummond is making progress but will not have this ready until later in the month due to travel/vacation time. 7) NEW BUSINESS 8) NEXT CALL The next call is next Thursday at the regular time. ## Action Items - Scott is going to take the example XRD from section 4.2.6 of the spec and generate a valid signature. This will give Nat an example, which he was asking for, and hopefully give us a real sample we can include in the spec. He will make sure the Signature is at the end of the document, as was discussed on the call - Will is going to update the spec to move the Signature element to the bottom of the document. If there is consensus from TC members unable to attend the call, he will also remove any language in the spec talking about linked XRDs. The previous processing language will be put back into place, specifying that linked resources should first be selected by whatever criteria are appropriate, and then sort that list in priority order. Any language on how to process linked XRDs will need to specified in another document, or added to XRD at a later time if it is deemed necessary.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]