Re: [xdi] RE: [External] Re: [xdi] PLEASE VOTE: XDI attribute instance syntax preference question

[Drummond Reed <drummond.reed@xdi.org>]

Bill, thanks for the feedback. Let me just provide a high-level response by addressing one key question you raised: "Since an XDI address is a dataweb version of a URI, why redefine something so ubiquitous to a non-standard meaning?"

What happened with the syntax simplification last spring was that we finally dropped that assumption, i.e., an XDI address is no longer considered to be just "a dataweb version of a URI", and by implication that the XDI address character set must be fully URI compatible.

This does NOT mean that an XDI address is not URI compatible. It only means that, like many other forms of identifiers that can be adapted to the Web, an XDI address MAY require URI encoding in order to be used as part of a URI.

Once we made the decision to change that design constraint, it allowed us to simplify the syntax signficantly because we could:

1. Begin using bracket delimiters for XDI context functions.
2. Narrow and tightly define the semantics of the XDI context symbols.

With regard to carrying XDI addresses in XML, I don't believe chevrons will be an issue because I expect that they will be enclosed in strings used as XML attributes just as all XDI addresses are expressed as strings in our JSON serializations.

As to your question, "is this the simplest possible syntax that gets 80% of what we want, but no simpler?", I can only say that it's best syntax we've been able to develop that is able to express all the requirements of the XDI graph model structure as defined in https://wiki.oasis-open.org/xdi/GraphModelStructure.

For me, the table on that page (which took us about four months to work out, based on the last nine years of work), is for XDI the very essence of the phrase, "as simple as possible but no simpler". There is not, in my personal opinion, a single line of that table that can be left out and still meet the semantic data interchange requirements of XDI. The syntax we have adopted is simply a reflection of the requirements expressed in that table.

If you believe there is a way we can simplify it further, i.e., apply the "80/20 rule" to this table, please do post a proposal. Otherwise we're ready to proceed with putting that table into the XDI Core 1.0 spec to provide the rosetta stone for understanding the XDI graph model and XDI syntax.

=Drummond 

On Mon, Aug 12, 2013 at 5:47 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

I vote for Option A . If I could I’d vote against any chevrons at all in XDI addresses, for a reason not listed in the vote email Drummond sent out.  Whatever we do, XDI addresses, and possibly XDI content, will need to be sent inside of XML content in addition to being used with JSON.  The idea that now with chevrons an XDI address cannot go inside an XML element without being escaped significantly lowers XDI’s chances of adoption. 

 

I also think # is a bad idea, for the simple reason that it has two meanings on the web already that are very well known: hashtags, and fragment identifiers.  Since an XDI address is a dataweb version of a URI, why redefine something so ubiquitous to a non-standard meaning?

 

In general, I am also against any paired bracketing delimiters in XDI addresses, and I notice a bunch have been added or are being discussed, presumably from the spring syntax revisions: < and >, [ and ], “ and “.   The reason I am against this is that is complicates the parsing and if you allow nesting it means depth information has to be maintained.  I realize that syntax change is not up for a vote, or the vote has passed.

 

Also, how can some X not start with Y but be prefixed by Y? Or do you mean preceded by (as in the token X must always be preceded by the token Y).

 

Lastly, I think there have been some great advances forward in XDI over the last year but I encourage folks to look specifically at the syntax changes and ask the following question: is this the simplest possible syntax that gets 80% of what we want, but no simpler?

 

I may be alone in this view, but I still think we can do what we need to do with just contexts(I don’t know how this is represented now), xrefs (parens, the single bracketing delim from before this year), personal identifiers (=), community identifiers (@), reserved words ($), tags (+), delegation (*, unnecessary between GCS started segments), persistent identifiers (!), relation (/), variables ($$ , probably not how they are done anymore) and backrefs (.. , my thing, never has been XDI TC adopted).   There is a lot of power in that set of symbols, RDF turtle syntax accomplishes a great deal with just <,>,/,@,””, _,:, ->.    Every extra bit of syntax you add increases XDI complexity.  In my opinion every increase in complexity added to a spec is taking a certain # of potential adopters and pushing them out the door, never to return.  A certain level of complexity is needed, but erring on the side of too simple is much better in my opinion than erring on the side of too complex.  You can always add complexity in new versions, but it is always hard to take complexity away from a published spec.

 

From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf Of Drummond Reed
Sent: Monday, August 12, 2013 4:42 AM
To: Markus Sabadello
Cc: OASIS - XDI TC
Subject: [External] Re: [xdi] PLEASE VOTE: XDI attribute instance syntax preference question

 

Markus, very good points. I would argue, however, that's it's not entirely "consistent attribute syntax" vs. "consistent instance syntax" for this reason: under option B, the following two rules still hold true:

1.     All instances (whether entity instances or attribute instances) will be prefixed with either ! (unordered) or # (ordered).

2.     All attributes will be enclosed in chevrons.

So while it's true that if we adopt option B, not all instances will START with a ! or # character, they are still PREFIXED with a ! or # character.

 

For that reason, I find it more consistent to enclose all attributes (whether classes, instances, or singletons) in chevrons, just as we enclose all classes (whether entities or attributes) in square brackets.

 

So I too vote for the change, i.e., Option B.

 

 

On Mon, Aug 12, 2013 at 1:29 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Pretty hard choice. I think the arguments about additional characters and about looking back or ahead are negligible. To me it really seems to be just about cosmetics and not about functionality.

While the change would make attribute syntax always consistent, it would make instance syntax inconsistent, i.e. entity instances and attribute instances would then look differently.
You can only have one of the two, either consistent attribute syntax, or consistent instance syntax.

Anyway, I vote for the change, i.e. Option B.

Markus

 

On Mon, Aug 12, 2013 at 9:53 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

From the last TC meeting I have an action item to post this poll to the mailing list.

 

Please respond by indicating whether for the syntax for instances of an attribute class you prefer:

1.      Option A below.

2.      Option B below.

3.      No preference.

OPTION A

This is our current syntax which does NOT include chevrons around instances of an attribute class.

=drummond+home[<+tel>]!1234&/&/"+1-206-222-2222"

=drummond+home[<+tel>]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001&/&/"+1-206-111-1111"

=drummond+home[<+tel>]#3&/&/"+1-206-222-2222"

 

OPTION B

This change would include chevrons around instances of an attribute class.

=drummond+home[<+tel>]<!1234>&/&/"+1-206-222-2222"

=drummond+home[<+tel>]<!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001>&/&/"+1-206-111-1111"

=drummond+home[<+tel>]<#3>&/&/"+1-206-222-2222"

 

NOTES

·         The only difference between the two is the addition of chevrons around instances of an attribute class.

·         The arguments FOR:

o    It will simplify XDI syntax because there be one consistent rule: all attributes ALWAYS must be in chevrons (whether classes, instances, or singletons).

o    It does not require "looking back" an additional arc to determine if an arc represents an attribute instance or an entity instance.

·         The arguments AGAINST:

o    It adds two more characters to the XDI address of an instance of an attribute class.

o    It requires looking at the second character to distinguish an attribute of an attribute class from an instance of an attribute class. (Both would now start with <, so you have to look at the second character— ! or # would indicate an instance, + or $ an attribute).