Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-07-01

[Drummond Reed <drummond.reed@xdi.org>]

Following are the minutes of the unofficial telecon of the XDI TC at:
 
Date:  Thursday, 01 July 2010 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Markus Sabadello
Joseph Boyle 
Kaliya Hamlin
Les Chasen
Drummond Reed 
Giovanni Bartolomeo 
Bill Barnhill 

The Idearpad link for this conference is:

    http://xdi.idearpad.org/3
    
The password is:

    turtle
    

1) WELCOMES

The TC welcomed longtime member Les Chasen (who is rejoining calls) and new member Kaliya Hamlin.


2) PDX EXAMPLE APPS WIKI PAGE
 
This page was posted at Joe Johnston’s request:
 
      http://wiki.oasis-open.org/xdi/PdxExampleApps
 
Drummond explained that this is now ready for TC members to populate.

Joseph asked whether we should import or reference external specs relevant to each area, e.g., Portable Contacts or Activity Streams. example: http://activitystrea.ms/head/json-activity.html. Drummond suggested that they should be linked, but in many cases new XDI dictionary vocabulary will be needed to design a fully-XDI-enabled version of the service.
 

3) XDI JSON SCHEMA
 
We returned to the whole topic of the JSON serialization format.
 
  http://lists.oasis-open.org/archives/xdi/201006/msg00022.html
 
Bill has not yet down a version of the PDX Example document converted into his JSON schema proposal. He believes he will get it down this long weekend.

Bill explained that his proposal includes explicit datatypes following the same approach of 

Drummond asked the question about graph equivalence ("isomophism"), i.e., are two XDI graphs isomorphic if one includes the type information and one does not.

Bill's answer is that they are not isomorphic.

Bill suggested that one solution is to declare a default type of $a$xsd$string for all literals unless they are explicitly typed.

Joseph asked about the value of  having explicit type information in the serialization format.

Drummond talked about the issue of whether the type information is expressed in the XDI graph or only in the serialization format (similar to comments).

One way to do this is the graph is to express the type information algorithmically. For example, let's take the following XDI graph:

=drummmond
    +age
        "52"
    +tel
        "+1.206.555.1212"
        
Now, if you apply the $is$a best practice at the XDI subject level, you would add the following statement:

=drummmond
    $is$a
        +person
    +age
        "52"
    +tel
        "+1.206.555.1212"
        
Now, if we applied the same pattern to typing literals, it would look like:

=drummmond
    $is$a
        +person
    +age
        "52"
    +age$is$a
        $a$xsd$integer
    +tel
        "+1.206.555.1212"
    +tel$is$a
        $a$xsd$string

Alternative suggested by Giovanni:

=drummmond
    $is$a
        +person
    +age
        "52"
+age
    $is$a
        $a$xsd$integer
+tel
    $is$a
        $a$xsd$string
        
Drummond agrees with Giovanni that inserting this dictionary info once is the most efficient way to include it. Or it can be referenced from an XDI dictionary. However if it is referenced, there needs to be a way to declare, for a particular XDI graph, whether the implied $is$a statements from a particular dictionary are also part of the graph.

[NOTE: summary of usage of $is$a right now:
1) to express datatype
2) to express subclassing
3) to express instance of]

**TBD: Will insert JSON version of above here** offline

As an example, the fragment of the JSON schema that says how to specify a float object value literal is:
{
    "type":"object", 
    "description":"Object value that is a xsd:float",
    "properties":{
        "float": {"type":"number", "description":"The value"}
    }
},
What you would have in the serialization is
...
    'float' : 3,
    

Joseph asked if Markus' X3 JSON format in his XDI4J implementation used only JSON strings right now. Markus said yes, that's how it works -- his impelmentation only uses the JSON string datatype now.

Markus suggested that he would add a method for asking for the datatype of a literal.

Bill also made a suggestion of revisiting the TC's previous decision about declaring both X3 Standard and X3J (X3 JSON) as required serialization formats for an conformant XDI server, and saying instead that the X3J format is the one required format, and all others are optional.

Joseph said that for programmers who know JSON now and become exposed to XDI through that, they are going to be interested in the native JSON types.
 
Bill: I agree, and think it's best to go with the most intuitive form, i.e. principle of least surprise.

Proposed by Bill...."Core spec: mandates JSON format must be supported, future profiles may specify that additional formats are supported, similar to HTTP content negotiation. The future specs would include XDI XML to be compatible with 'Enterprise' shops. I'm not sure the business case for X3 Standard, other than to support existing software base.". Note: my motion is that we adopt *a* JSON format as the format, what the schema will be for that format is TBD. The schema I'm proposing is only one option, and can be considered an initial straw man.

Bill: Concern was expressed by others that we need to see an example of one way to serialize X3J (one schema possibility in an example) before a decision is made.

Markus is hesitant to "put all our serializing eggs in the JSON basket" because he feels X3 Standard is the most efficient and parsable format.

ACTION ITEMS ON THIS TOPIC:

#1: Bill to produce his proposed version and with an example of the PDX example document.

#2: Joseph to start an email thread to discuss the implementation issues.
 
 
4) NEXT CALL

Drummond is going on vacation for the next 10 days and may be able to make next week's call but will not be able to attend in two weeks (that's his return day). However, Bill will chair the call, so let's drive ahead full speed. The faster we can move through issues, the sooner we will have XDI 1.0 specifications.