[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Entity - attribute boundary
Wow, Joseph, that's a major head-banger. I must admit it is very clean -- there absolutely is the demarcation point between entities and attributes in any XDI address that contains attributes.However here are the downsides as I see them (with about 5 minutes thought, after a redeye to London so I may not be thinking that clearly):
- A parser would no longer be able to tell just from looking at a particular arc whether it represented an entity or an attribute, but would have to look at the larger context.
- Since we still need bracket syntax for: a) roots, b) collections, c) definitions, and d) variables, it would seem to break the pattern if we didn't use it for attributes.
- It would suggest that the demarkation point itself should be a context node, but we have said that complicates the model, so we shouldn't do that. In that case this special character would only modify one arc (the first attribute), which seems inconsistent.What do others think?BTW, I did work on the plane to prepare an answer to your question about why to have the distinction between entities and attributes, since it's something we need to explain in the XDI Core spec anyway. I will try to upload that later today or tomorrow (depending on sleep schedules ;-)=DrummondOn Tue, Nov 12, 2013 at 8:59 PM, Joseph Boyle <firstname.lastname@example.org> wrote:
Now that attributes strictly follow entities:xdi-address = *peer-root *inner-root *entity-node *attribute-node [ attribute-instance value-arc]Wouldn't it be sufficient to have one character after all entities and before all attributes?xdi-address = *peer-root *inner-root *entity-node "|" *attribute-node [ attribute-instance value-arc]Then all following arcs (except a final &) would be known to be attributes without having to individually enclose in < >.