[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-08-20
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 20 August 2009 USA Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) ATTENDING Will Norris Scott Cantor Eran Hammer-Lahav Drummond Reed Bob Morgan Markus Sabadello John Bradley Nat Sakimura AGENDA 1) PUNCHLIST OF XRD 1.0 ISSUES The punchlist of remaining issues for XRD 1.0 WD05 is posted at: http://wiki.oasis-open.org/xri/XrdOne/SpecHome Following are decisions about each one -- and corresponding action items in certain cases. 1A) SCHEMA ISSUE: RELAX OR XSD? We have a key issue: there is no valid RelaxNG schema for XML dSig. Since we inherit a significant portion of it for XRD signatures. Should we switch to XSD? #DECISION: It is more practical to use XSD. #ACTION: Scott will produce a normative XSD and eliminate wildcards that are not namespace qualified. 1B) KEYWORDS IN UPPERCASE Will agrees we should do this. Unless anyone disagrees, we will make this change. Ideally this is done as part of either the DocBook template or the CSS display. #DECISION: Yes, we will put all keywords in UPPERCASE. #ACTION: Will will try to have the DocBook template or CSS modified (and will fall back to manual changes if necessary). 1C) ALIAS ELEMENT DEFINITION Need to close on aligning this with Subject, i.e., will we add the match attribute? John pointed out that the actual identifier that is produced after the match is the Subject (or Alias if using that element) -- the pattern itself is not the Subject or Alias. We might want to put in a warning to be careful about this. #DECISION: Yes, we should align the two. #ACTION: Will will update the spec. 1D) EXPIRES AND CACHING What do we say about the relationship of XRD:Expires and caching semantics of specific transport protocols? #DECISION: Expires is transport-protocol independent. "The semantics of the XRD:Expires element apply to the metadata available in the XRD document and are independent of the caching semantics of any transport protocol used to retrieved the XRD." 1E) URI TEMPLATE VARIABLE NAMES Three issues: A) DEFINING OUR OWN URI TEMPLATE VARIABLE NAMES FOR #SEE-ALSO RELS Eran said that host-meta will define a default generic template dictionary - one that will be used if there is no other dictionary defined. However he cautioned that this dictionary should apply only to host-meta, and the behaviour should be undefined for any other XRD. #DECISION: We will say nothing. B) CONFLICTS IN URI TEMPLATE VARIABLE NAMES WITH MULTIPLE RELS Eran felt that although this could happen, it was an edge case. Rel specs need to define URI template variables (dictionary) and how they are calculated. The XRD consumer must then process the dictionaries for each rel that applies to the link. Hopefully there are no conflicts. It was agreed that namespacing for template variables is too complex to apply here. #DECISION: If the dictionary is incomplete, or if there are conflicts, the behaviour is undefined, and we will state this explicitly in the spec. We will also warn against XRD providers creating this kind of condition in links. #ACTION: ERAN will add a paragraph in the appropriate place in WD05. C) MISSING URI COMPONENTS #DECISION: The input does not have a component matching a variable, it will replace the variable with the empty string. #ACTION: WILL to note this in WD05. 1F) NAME FOR REL FOR LINKED XRD (CURRENTLY #SEE-ALSO) Drummond has some misgivings about #see-also. Will and Drummond discussed this and see three options: a) #see-also (or something else from the SemWeb) b) #equiv-xrd (or something similar we define that is explicitly ours) c) #application/xrd+xml (the mime type) #DECISION: We will stay with #see-also. 1G) SUBJECT MATCHING FOR XRIS We agreed to defer this. 1H) REPLACEMENT FOR TERM "XRD CONSUMING APPLICATION"? This occurs 26 times in the spec. Potential replacements are either "XRD consumer" or "XRD processor". #DECISION: We will make it uniform throughout the spec to use "XRD consumer" and "XRD provider". 1HA) RESOURCE NAMES FOR SOURCE RESOURCE AND TARGET RESOURCE #DECISION: 1) In the link section, from the Link Header spec about standard terminology for describing links. 2) Through the rest of the spec, consistently use "Resource described by the XRD" and "Linked resource" 1I) XRDS SECTION By adding a short section at the end (it would become section 5 and Conformance would become section 6), the XRD spec would also be authoritative for the super-simple XRDS wrapper needed to define a sequence of XRDs. XRI Resolution 3.0 is not the only application that needs this - any potential application (such as grid computing) that wants an XRD processor to navigate a set of linked XRDs based on some discovery criteria and report back the resulting path will need an XRD sequence. Eran suggested the wording: "In cases where you want to put together multiple XRDs in the same document...." And also the warning, "You should NOT use this unless you need a sequence." #DECISION: We will add this as section 5, using the wording above, and we will not add a separate namespace. #ACTION: DRUMMOND to prepare text and send to Will. 2) LRDD - SUBJECT OF A HOST-META XRD http://lists.oasis-open.org/archives/xri/200908/msg00007.html Eran said he realized that LRDD is "more like a cookbook" than a protocol spec. It is really a spec for extending the link framework for how you associate resource on the Web. He feels that if he takes this approach with the next draft, the XRD spec only needs a few paragraphs to explain how discovery of an XRD can be performed using HTTP/S. #ACTION: Eran to add a short section to WD05 with the reference to the updated draft of LRDD as soon as its ready. 3) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES Drummond reported he posted Working Draft 02 before today's call. There are no outstanding issues. He will keep working diligently on WD03. 4) SCHEDULE Nat asked what the overall schedule is looking like. The general consensus was: * XRD 1.0 at Committee Draft 01 vote within 2-3 weeks. * XRI Syntax 3.0 ready for Committee Draft vote by end of Sept. * XRI Resolution 3.0 and the XRI/URI Bindings (http/https, mailto, info) by mid-fall. 5) NEXT CALL Next week at the regular time.