Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-08-20

["Drummond Reed" <drummond.reed@cordance.net>]

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.