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: [External] Re: [xdi] PLEASE VOTE: XDI attribute instance syntax preference question


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).

 

 

 

 



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