1 / 7

Strawman Object model for XDI

Strawman Object model for XDI. for the discussion at XDI f2f meeting New Orleans 2004-04-29 Nat Sakimura. XDI Intro Whitepaper model is hard to read …. and, some of the requirements are not met. Proposed Straw man XDI Object Model (extremely rough and incomplete sketch for discussion).

gaston
Download Presentation

Strawman Object model for XDI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Strawman Object model for XDI for the discussion at XDI f2f meetingNew Orleans 2004-04-29 Nat Sakimura

  2. XDI Intro Whitepaper model is hard to read… and, some of the requirements are not met.

  3. Proposed Straw man XDI Object Model (extremely rough and incomplete sketch for discussion) Changes: • Inheritance used. • Resources has more <tags> for efficiency • Contract is a subclass of Resource, thereby introducing further structure • Some elementally methods shown.

  4. 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. Some Considerations on Resources • type – dictates what object type this XDI document is • ename – for efficiency • enumbers – must have at least one of this. • links – links to external XDI documents • ref – links to the enveloping XDI document • resources – Resource can contain other resources. • effectiveDate – do we need it? • expiryDate – ditto • cacheable – ditto • cachePeriod – ditto

  6. Some considerations on Contracts (link in the whitepaper) • parties – contracts are among two or more parties. • jurisdiction – any contract needs jurisdiction • Other standard feature of contracts needs to be added as well? Or – should we construct each part as sub-resources? (see next slide) • templateID – a resource with human readable data in which parties are written as variables can be used as template. This, combined with parities above, can derive a human readable contract. (Note: xri itself will be the machine readable version of the contract template. ) • date – maybe needed only as the part of dsigs? • dsigs – XML digital signature

  7. 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> Should we stick with the generics? 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>.

More Related