[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xdi] RE: [External] Re: [xdi] PLEASE VOTE: XDI attribute instance syntax preference question
|
Thanks Drummond. I remembered that we had said we weren’t restricting XDI addresses to URI syntax anymore. I’m not talking about the syntax however, but the semantics. An
XDI address identifies a dataweb resource, it performs a similar function to a URI, and so people are likely to expect the same kinds of rules to apply. You will have people using query strings, thinking # indicates fragment identifiers, or hashtags. It
can be overcome, especially with all the benefits an XDI address provides, but for me it boils down to the principal of least surprise. Why violate that if you don’t have to?
Which, btw is a question you addressed…you said you think each rule in that table is necessary for the XDI goals and that seems to be the TC consensus. 56
different types of nodes in the graph seems more than needed to me from a gut instinct, and I’ve discussed my specific reasoning based on implementation experience on the list, so I won’t go into again. I’ve also made proposals before but most haven’t carried,
or morphed into someone else’s proposal with some changes, so my thought is that this is what the TC wants. I don’t intend try to change it at this point, but felt the need to voice some caution again. My thoughts will coalesce in ADDI, the Asynchronous
Data Discovery and Interchange protocol I’ve mentioned before. If the ideas there work and the TC wants then perhaps I can adopt some of that into XDI proposals for the next version of XDI. You mentioned “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”,
I believe you will need to encode chevrons as entities in attributes values, or the parser will error out. More specifically, I think you can have > unencoded in an attribute, but since < signifies the start of an element it needs to be <.
Bill From: drummond@respectnetwork.net [mailto:drummond@respectnetwork.net]
On Behalf Of Drummond Reed 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
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.
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]