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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: Minutes: XDI TC Telecon Thursday 2006-12-14


Following are the minutes for the unofficial XDI TC telecon at:

Date:  Thursday, 14 December 2006 USA (Friday morning Asia)
Time:  3:00PM - 4:00PM PT

ATTENDING

Gabe Wachob
Bill Barnhill
Steve Churchill
Drummond Reed
Les Chasen
Laurie Rae


AGENDA

1) CHARTER UPDATE DISCUSSION
We reviewed the proposed charter update draft posted on the XDI TC wiki at:

	http://wiki.oasis-open.org/xdi/CharterRevision02

* Steve and others made the point that it doesn't include the SQL analogy
developed by Andy Dale. This needs to be added.
* Gabe and others made the point that to keep it simple, in terms of a
protocol, we should define a simple abstract interaction model and then an
http binding, and then leave future bindings undefined until they are
needed.
* It was also agreed that it will need to reflect an updated IPR statement
once we have complete that vote.

# DRUMMOND to commence IPR Transition Vote.

# DRUMMOND to update charter draft on the wiki per the feedback above.

2) V18 SCHEMA
Drummond posted a v18 schema using the subject/predicate/object element
names along with several example documents at:

	
http://www.oasis-open.org/committees/download.php/21522/draft-xdi-schema-v18
.xsd
	
http://www.oasis-open.org/committees/download.php/21523/v18-Example-Bizcard-
v1.xml
	
http://www.oasis-open.org/committees/download.php/21524/v18-Example-Dictiona
ry-v1.xml

* Drummond explained that the only substance change was the cardinality of
the xri child element of the link element, which is now 0-or-more instead of
1-or-more. He and Steve agreed this requires the following XDI new
addressing rule: the value of the required ref child element(s) of a link
element, cast as a cross-reference, is considered an implicit value of the
xri child element from the standpoint of XDI addressing, EXCEPT if such an
implicit value is overridden by the same value used explicitly. See the
following three examples.

EXAMPLE 1:

<subject>
	<xri>+foo</xri>
	<link>
		<ref>+bar</ref>
	</link>
</subject>

In this example, the xri +foo*(+bar) addresses the link whose ref value is
"+bar" because the implicit XRI for the link whose ref value is "+bar" is
"(+bar)".

EXAMPLE 2:

<subject>
	<xri>+foo</xri>
	<link>
		<ref>+bar</ref>
	</link>
	<link>
		<xri>(+bar)</xri>
		<ref>+raz</ref>
	</link>
</subject>

In this example, the xri +foo*(+bar) addresses the link whose ref value is
"+raz" because the implicit XRI for the link whose ref value is "+bar" is
overridden by the explicit XRI used to address the link whose ref value is
"+bar". (This seems like a strange case but still one that must be accounted
for.) Note that this "strands" the link whose ref value is "+bar" because,
without an explicit xri element, and with its implicit address overridden by
another link element, there is now no way to address this link. Example 3
solves this problem:

EXAMPLE 3:

<subject>
	<xri>+foo</xri>
	<link>
		<xri>(+raz)</xri>
		<ref>+bar</ref>
	</link>
	<link>
		<xri>(+bar)</xri>
		<ref>+raz</ref>
	</link>
</subject>

In this last example, the xri +foo*(+bar) still addresses the link whose ref
value is "+raz", but now the link whose ref value is "+bar" is no longer
stranded because it has an explicit xri element with a value of "(+raz)". So
+foo*(+raz) references an XDI subject with the XRI "+bar", and +foo*(+bar)
addresses a subject with the XRI "+raz". (Again, I see no explicit use case
for doing this, but illustrates how the rule works.)

* There was discussion that while the new subject/predicate/object
terminology is purely human-readable semantics and makes no actual change in
the underlying XDI data model, it introduces interesting but not always
intuitive interpretations of the data model. TC members need more time to
consider these new RDF-based semantics.

* There is agreement, however, that the real semantics of the XDI
"three-level" or "three-dimensional" data model lie in the three
levels/dimensions and not in the element names.

* Regardless, there was consensus that once the XDI 1.0 cycle is done (if
not sooner), we need to author a document about the relationship of XDI and
RDF.


3) XPL (XRI PATH LANGUAGE) DISCUSSION
We discussed Bill's proposed XRI Path Language and how it could serve as a
simple query syntax. See:

	http://lists.oasis-open.org/archives/xdi/200612/msg00008.html

* Marty asked several conceptual questions about Bill's XPL proposal. One of
them is whether it operates against XRIs or the XDI data elements identified
by the XRIs. Bill clarified that it is intended to operate against the
identified data elements, however it could also be used across a set of
XRIs. This needs further exploration.

* We discussed the idea about naming cross-references using segment
indicators. The concensus is that parentheses remain preferable.

* Bill would still like to see an $ Dictionary entry for variables. This
would add functionality similar to regular expressions, and allow those
expressions to be named. Bill's current favorite was $$, but he is open to
any proposal. ($(variable-name)) was suggested, since it represents a
"private root" in the $ space and thus would work well for variables. Bill
pointed out that this is similar to Ruby which uses ${expression}.

# BILL to play with this syntax and provide feedback to the list on how it
works.








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