We need to support literals other than strings in XDI, in my opinion.
As for the second part, how is (1)
=bill.barnhill+icon /!/(..the string value..) =bill.barnhill+icon$t /!/(..the mime type..)
better than (2)
=bill.barnhill+icon /!/(..the percent encoded value..) =bill.barnhill+icon /$t/+image*gif or (3)
=bill.barnhill+icon /!($t/+image*gif)/(..the percent encoded value..)
or (4), where type info is in XDI dictionary,
=bill.barnhill+icon /!/(..the percent encoded value..)
Frankly I think (3) or (4) are the best. For example let's say I have GIF and SVG versions of the icons:
=bill.barnhill+icon /!($t/+image*gif)/(..the percent encoded value for GIF data..) =bill.barnhill+icon /!($t/+image*svg *xml)/(..the percent encoded value for SVG data..)
Given the richness of mime types I would imagine we're going to want to represent them as XRIs for XDI applications, with a transformation to a text based mime type value, maybe via +image*gif+label /!($/+text*plain)/image%2Fgif
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
From: markus.sabadello@gmail.com [markus.sabadello@gmail.com] on behalf of Markus Sabadello [markus.sabadello@xdi.org]
Sent: Thursday, February 09, 2012 3:20 PM
To: Barnhill, William [USA]
Cc: Drummond Reed; OASIS - XDI TC
Subject: Re: [xdi] New versions of 3 key XDI docs posted
My understanding is that a literal doesn't carry any extra information, and that it doesn't have to be an XRI, URI or IRI.
It's just a string.
If you want to have extra information for a literal, I bet Drummond would say that this is exactly why he just came up with the new concept of literal contexts.
I.e. information such as a timestamp or mime type would go into that context rather than be an intrinsic part of the literal.
So you'd have.
=bill.barnhill+icon/!/(..the string value..)
=bill.barnhill+icon$t/!/(..the mime type..)
Markus
On Thu, Feb 9, 2012 at 9:07 PM, Barnhill, William [USA]
<barnhill_william@bah.com> wrote:
You could do that, but the content within the cross-reference is supposed to be an XRI, URI, or an IRI, right?
Also, if you look at the object you can't tell what it is : (R0lGODlhEAAOALMAAOazToeHh0tLS_7LZv_0jvb29t_f3__Ub__ge8WSLf_rhf_3kdbW1mxsbP__mf___yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj_gAwXEQA7)
By making it a data URI you can:
(data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS_7LZv_0jvb29t_f3__Ub__ge8WSLf_rhf_3kdbW1mxsbP__mf___yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj_gAwXEQA7)
However if you said the following you could get rid of data URL:
- A percent-encoded octet stream is the object value if the predicate is rooted at !, or the last subsegment of the subject is !. This is a special case, which I don't like - but it could work
- A predicate of ! conveys no additional information about the octet stream.
- You can add information through additional sub-segments, such as specifying the mime-type like so
- !(+mimetype/$is/+image*gif) or !(+mimetype/$is/+text*plain)(+lang/$is/$en). These could probably be shortened with other choices for dollar words, or could be put into separate XRIs in the same graph like so =bill.barnhill+icon!/+mimetype/+image*gif.
- Alternatively, you can add information within XDI dictionary. For example if =bill.barnhill is a +person (I hope so ) the following XDI XRIs are defined. Btw, sketchy on these being compatible with current model, feel free
to correct.
- +person/$has/+icon
- (+person/+icon)/$is$a/!(+mimetype/image/gif)
- Type information specified in the XDI dictionaries takes precedence, and behavior is undefined if the type info is specified in both places
- Type information in local XDI dictionaries take precedence over type information in the global XDI dictionary.
- The absence of any type information either from dictionaries or locally means the mime type of the literal is application/octet-stream.
- The XDI client API should have a method toXRI() that converts any literal to an XRI. This XRI will be a data URI cross-reference with the appropriate mime type specified and percent encoding used.
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
Do we have to use the data URI scheme?
Why not just say
=bill.barnhill+icon/!/(R0lGODlhEAAOALMAAOazToeHh0tLS_7LZv_0jvb29t_f3__Ub__ge8WSLf_rhf_3kdbW1mxsbP__mf___yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcppV0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj_gAwXEQA7)
That's simply the URL-safe Base64 in parens..
Markus
On Thu, Feb 9, 2012 at 2:56 PM, Barnhill, William [USA]
<barnhill_william@bah.com> wrote:
Drummond,
Using the terminal notation how would you encode the XDI statement saying that the inlined icon for ="" is
data:image/gif;base64,R0lGODlhEAAOALMAAOazToeHh0tLS/7LZv/0jvb29t/f3//Ub/
/ge8WSLf/rhf/3kdbW1mxsbP//mf///yH5BAAAAAAALAAAAAAQAA4AAARe8L1Ekyky67QZ1hLnjM5UUde0ECwLJoExKcpp
V0aCcGCmTIHEIUEqjgaORCMxIC6e0CcguWw6aFjsVMkkIr7g77ZKPJjPZqIyd7sJAgVGoEGv2xsBxqNgYPj/gAwXEQA7
Or using terminals would you just not encode any binaries into XRIs? If so this would cause some problems, and I think XDI should be able to support binary data.
Alternatively there could be a method that works with terminal notation for specifying the encoding of the literal (or language for strings), something like !($mime/image/gif) with the literal value being the binary data.
Also, how is the use of ! as denoting a persistent identifier distinguished versus ! as data predicate?
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
XDI TC Members and Observers,
I just uploaded new native and PDF versions of the three key docs we've been using to document the evolution of the XDI graph model towards our 1.0 specification suite.
Please review these before the call if you can so we can dive right into the main topics of the call.
Below is the set of public links (as always, all of these are also consolidated on a single page on the XDI TC wiki:
http://wiki.oasis-open.org/xdi/XdiGraphModel):
XDI GRAPH MODEL - 21 page Word doc explaining the core model
XDI GRAPH PATTERNS - 14 page Powerpoint doc with examples of all basic patterns
XDI STATEMENTS FOR XDI GRAPH PATTERNS - 8 page Word doc with XDI statement sets corresponding to each of the example graphs in the above. STRONGLY RECOMMENDED TO READ IN PARALLEL WITH XDI GRAPH PATTERNS.
A summary of the key changes in these new versions:
- They show the use of literal contexts - modeling an RDF literal as an XDI context with a single literal arc represented by the XRI "!" and the XDI object node containing the literal value. (See detail below.)
- They show the use of nested root contexts - root nodes (open circles) below the current root node that identify other local XDI graphs. (See detail below.)
- They show the use of root contracts - the "bootstrap" link contract needed off an XDI root node to establish root-level permissions for an XDI local graph (and show the network origin of an XDI message).
- The ordinal context pattern (using *1, *2, etc. as contexts to explicitly order XDI graph nodes) is now more explicitly defined and illustrated.
- In the XDI Graph Patterns doc, more example graphs have been added, and more explanation for each graph, to make it easier for newcomers to understand the different patterns and how they fit together.
The advantages of the literal context proposal:
- It gives every literal in the XDI graph its own XDI address without using a cross-reference - simplifying navigation and XRI processing time.
- It makes it much cleaner to express and navigate XDI metadata, such as datestamps and versioning.
- It simplifies parsing and serialization, since all semantics describing a literal will be in the XDI subject identifying it, and every XDI literal (now called a "terminal") will have an XDI predicate consisting only of "!". (Note that Victor Grey
has suggested another XRI delimiter character could also be used for this - he suggests ":").
The advantages of the nested root contexts proposal:
- It provides a clean way to model the relationship of different local XDI graphs available at different XDI network endpoints for the purposes of XDI discovery.
- It shows how a single physical XDI server (such as an LDAP server, SQL database, NOSQL database, etc.) can implement a "multi-tenant" model where it can host multiple independent local XDI graphs yet still have them logically appear as part of the global
XDI graph.
I will put these proposals on the agenda for tomorrow's telecon.
=Drummond
|