1

Strawman Object model for XDIStrawman Object model for XDI

for the discussion at XDI f2f meetingfor the discussion at XDI f2f meetingNew OrleansNew Orleans2004-04-292004-04-29

Nat SakimuraNat Sakimura

2

© 2004 NRI© 2004 NRI

XDI Intro Whitepaper model is XDI Intro Whitepaper model is hard to read…hard to read…

and, some of the requirements are not met. and, some of the requirements are not met.

3

© 2004 NRI© 2004 NRI

+new()+set()+get()+delete()+destruct()

Object

+normalize()+validate()+asIRI()+asAnyURI()+asURI()

- data : char

Xri

- type : Xri- enumbers : Xri- enames : Xri- link : Xri- ref : Xri- data : char- resources : Resource

Resource

+resolve()

Resolver

- parties : Xri- jurisdiction : Xri- templateId : Xri- date : Xri- dsig : dsig

Contract

Registry

dsig

- data : char

String

XML

Proposed Straw man XDI Object Model Proposed Straw man XDI Object Model (extremely rough and incomplete sketch for (extremely rough and incomplete sketch for discussion)discussion)

Changes:

• Inheritance used.

• Resources has more <tags> for efficiency

• Contract is a subclass of Resource, thereby introducing further structure

• Some elementally methods shown.

Resource

-resources : Resource [0..*]

-enumbers : Xri [1..*]-enames : Xri [0..*]

-links : Xri [0..*]-ref : Xri [0..*]

-type : Xri [1]

+presentContract( contract : Contract )+acceptContract( contract : Contract )

+destruct()+delete()

+new()+set()+get()

Object

Contract

-jurisdiction : Xri [1]-templateID : Xri [1]

-dsigs : dsig [2..*]

-parties : Xri [2..*]

-date : Xri

Xri

+asAnyUri()+asUri()

+asIRI()

String

-data : char [*] +resolve( xdi )

Resolver

Registry

dsig

XML

4

© 2004 NRI© 2004 NRI

Resource

-resources : Resource [0..*]

-enumbers : Xri [1..*]-enames : Xri [0..*]

-links : Xri [0..*]-ref : Xri [0..*]

-type : Xri [1]

+presentContract( contract : Contract )+acceptContract( contract : Contract )

+destruct()+delete()

+new()+set()+get()

Object

Contract

-jurisdiction : Xri [1]-templateID : Xri [1]

-dsigs : dsig [2..*]

-parties : Xri [2..*]

-date : Xri

Xri

+asAnyUri()+asUri()

+asIRI()

String

-data : char [*] +resolve( xdi )

Resolver

Registry

dsig

XML

links in Resource may be a bad naming as it can be confused with links in the whitepaper. It simply is a link to the external document. Link in the witepaper is more akin to Contract here.

5

© 2004 NRI© 2004 NRI

Some Considerations on Some Considerations on ResourcesResources

type – dictates what object type this XDI document isename – for efficiencyenumbers – must have at least one of this. links – links to external XDI documentsref – links to the enveloping XDI documentresources – Resource can contain other resources. effectiveDate – do we need it? expiryDate – ditto cacheable – ditto cachePeriod – ditto

6

© 2004 NRI© 2004 NRI

Some considerations on Some considerations on Contracts Contracts (link in the whitepaper)(link in the whitepaper)parties – contracts are among two or more parties. parties – contracts are among two or more parties.

jurisdiction – any contract needs jurisdiction jurisdiction – any contract needs jurisdiction Other standard feature of contracts needs to be added as well? Other standard feature of contracts needs to be added as well? Or – should we construct each part as sub-resources? (see nexOr – should we construct each part as sub-resources? (see next slide)t slide)

templateID – a resource with human readable data in whitemplateID – a resource with human readable data in which parties are written as variables can be used as templatch parties are written as variables can be used as template. This, combined with parities above, can derive a humae. This, combined with parities above, can derive a human readable contract. (Note: xri itself will be the machine ren readable contract. (Note: xri itself will be the machine readable version of the contract template. ) adable version of the contract template. ) date – maybe needed only as the part of dsigs? date – maybe needed only as the part of dsigs? dsigs – XML digital signaturedsigs – XML digital signature

7

© 2004 NRI© 2004 NRI

Should we stick with the Should we stick with the generics?generics?

Generics as in the Whitepaper

<xdi:resource> <xdi:xri>:1:3:58</xdi:xri> <xdi:xri>=John_Smith</xdi:xri> <xdi:xri>=Johnny</xdi:xri> <xdi:resouece> <xdi:xri>(+type)</xdi:xri> <xdi:xri>:1:3:58:3</xdi:xri> <xdi:data>(+person)</xdi:data> <xdi:resource>….</xdi:resource>

Expanded

<xdi:resource> <xdi:type>(+person)</xdi:type> <xdi:enumber>:1:3:58</xdi:enumber> <xdi:ename>=John_Smith</xdi:ename> <xdi:ename>=Johnny</xdi:ename>…</xdi:resource>

Sticking with the generics may be esthetically appealing, but may be inefficient in the implementation.

We don’t have to register the fact that :1:3:58 is type +person as addressable resource. It has no use, and the registration is very expensive computationally. More over, it is much easier to constrain that the particular resource has only one type if we had <xdi:type>.