OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xdi] Exciting development: XDI graph model documented - please indicate your syntax preferences!

On Apr 11, 2013, at 8:07 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

Just to be clear, I don't think this addressability distinction doesn't have to do with entities or attributes. Both can contain other entities or attributes. It has to do with describability. For example, in XML, an element can contain a subelement to describe the parent element. And subelements can contain other subelements, etc. So XML elements are describable.

I remember (but don't have source handy) that attributes vs entities is one of the biggest thing that developers disliked about XML, seeing it as unnecessary complication, that led them to embrace JSON.

Another viewpoint is that JSON arrays are like children and JSON objects are like attributes. http://blog.technologyofcontent.com/2010/01/json-vs-xml/

However in XML, attributes cannot contain other attributes. For example, if have an person element with a weight attribute, you can't put a timestamp attribute on the weight attribute.

Below I think you say that in XDI attributes can contain other attributes - if so this is not a difference between attributes and entities in XDI. So I am still trying to come up with why they need to be distinguished.

So in the case of an address, if you need to be able to separately describe address line 1, address line 2, and address line 3 -- for example, to say that only address line 1 is required, or that address line 3 includes a special requirement - then you need for each address line to be separately addressable in XDI and not just JSON. (If you didn't need that describability, you could just specify in the dictionary that &+address takes a JSON array as its value, and then specify the array in JSON schema.)

Yes - my idea was that the first and second address lines would continue to be addressable in XDI, even though the two values can potentially be set via a single statement, and also potentially retrieved collectively.

In programming terms this means XDI data would be "typed" or "strongly typed", like in Java and C/C++, and unlike _javascript_, Python, Perl, Ruby, etc. This surprises me and doesn't seem like a natural fit for JSON.

It may not be a natural fit for JSON but it seems like a hard requirement for a semantic data interchange format. I'd put it this way: even though we want the JSON serialization of XDI graphs to be very friendly to developers, and we want the XDI graph model to leverage the very simple and elegant JSON data model, XDI does not equal JSON (if it did, we wouldn't need XDI).

Another example I thought of later was that SQL declaration of fields states them to be of one of its basic types.

However semantic specification seems to me to be mostly orthogonal to datatype specification. You can have either of them without the other - you could know that a field is an address, but find it useful to allow various kinds of data in it, string, list of string, number, etc. - or you could have a field which is semantically ambiguous or unspecified, but always a single string - or both or neither

 Good suggestions. I particularly like colon as it's exactly what's used by JSON.

I think it's the best so far for this purpose too.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]