[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Improving Higgins XDI syntax
|
Paul, see inline for answers to your XDI-related questions.
=Drummond
On Thu, Aug 5, 2010 at 11:47 AM, Paul Trevithick
<ptrevithick@xxxxxxxxx> wrote:
Whereas over the long haul there are lots of semantic changes [1] we'd like to make to the XDI that Higgins is exposing, in the very short term there is an urgent need to make it far less verbose and more developer/human friendly the XDI on a syntactic level. I'm concerned about the aesthetics and verbosity.
I've collected here [3] some suggestions for how it could be improved. I repeat [3] here:
The XDI below contains a repeated idiom for representing complex attributes (object-valued predicates) that is far more verbose than required. Every section represented like this:
<xdi:xdi>
<xdi:s xri="$value$hash$sha$256!f68f4bb3513a89c6ea41b6eeffe6af0ea2a7d2f3f172b72bf26ecb29d9713020">
<xdi:p xri="$value">
<xdi:data><![CDATA[urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5]]></xdi:data>
</xdi:p>
</xdi:s>
</xdi:xdi>
...should be written like this:
<xdi:ref xri="=(urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5)"/>
Similarly, since in every case above there is only a single value for a literal, every section that looks like this:
<xdi:xdi>
<xdi:s xri="$value$hash$sha$256!0a38e8a3c328b1616ac3c34720d0ceb578bd3f5e8bfff9841bb0804dd4d2b5eb">
<xdi:p xri="$value">
<xdi:data><![CDATA[55555-1234]]></xdi:data>
</xdi:p>
</xdi:s>
</xdi:xdi>
</xdi:p>
...should look like this:
<xdi:data><![CDATA[55555-1234]]></xdi:data> <-- Drummond/Markus please verify
</xdi:p>
Other Ideas
*Should we be using the JSON serialization of XDI instead of the XML serialization?
That really depends on what your customers want, but my recommendation is "Yes". XDI is already fully structured data and JSON is a structured data format, so it's less verbose, easier to read, and faster to process. The XDI TC has already decided to make JSON the primary serialization format we are going to concentrate on in the short term (with X3 being the other option, which is very close to JSON).
*It would be nice if XDI had a convention for URI shortening based on a default namespace. That if relative entityIDs were used (e.g. "#245") we wouldn't have to have these long entityIDs like this one used below: "urn:efa25e71-5b6f-4844-b139-4ed26dd1c3e5".
Interestingly, the example you use - of a URN - is not an address that can benefit from namespacing. All URNs are globally unique.
However other URIs used for namespacing, especially Cool URIs, could benefit from having a namespacing facility in XDI serialization. It's just a matter of priority on the very long XDI specification wish list. Do you want to bring that up directly with the TC?
Yes.
*The above example could be significantly shortened if it only described a single address (the second address doesn't have any illustrative value).
For reference here is an RDF representation of a single persona (Contactable_1) and their address, name and telephone number. Some "cheating" is going on here: entityIDs have been hand-crafted to be pretty (e.g. :Address_1 vs. :efa25e71-5b6f-4844-b139-4ed26dd1c3e5):
:Contactable_1
rdf:type p:Contactable ;
p:role p:Buyer ;
vcard:adr :Address_1 ;
vcard:n :Name_1 ;
vcard:tel Voice_1 .
:Address_1
rdf:type vcard:Address ;
vcard:extended-address "Suite 1000"^^xsd:string ;
vcard:locality "Peoria"^^xsd:string ;
vcard:postal-code "61604"^^xsd:string ;
vcard:region "IL"^^xsd:string ;
vcard:street-address
"123 S Main Street"^^xsd:string .
:Name_1
rdf:type vcard:Name ;
rdfs:label "Name_1"^^xsd:string ;
vcard:family-name "Jones"^^xsd:string ;
vcard:given-name "Alice"^^xsd:string .
:Voice_1
rdf:type vcard:Voice ;
rdf:value "tel:+358-555-1234567"
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
