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] XDI collection as attribute

This reminds me that XDI2 still allows [#] and [$], I wonder if anything breaks if I remove this from the code (probably not).

We used to call this a "metaclass", but I'm not sure what its purpose was.


On Tue, Sep 16, 2014 at 7:13 AM, =Drummond Reed <drummond.reed@xdi.org> wrote:
On Mon, Sep 15, 2014 at 9:57 PM, Le Van Gong, Hubert <Hubert.LeVanGong@neustar.biz> wrote:

My ultimate goal is to be able (programmatically) to distinguish entity collections from attribute collections since I understand (please confirm!) that the former should be represented with a circle (i.e. like an entity) whereas the latter will be a diamond (i.e. attribute).

Parsing the ABNF, it seems an attribute collection will always look like: [<+name>] or [<$name>]
while an entity collection will never start with [< nor end with >]
Am I correct?


Note that the legal collection ABNF def seems weird to me as I interpret it as: [@]
Shouldn't there be an XDI name after the '@' ?
In which case, the definition should be:
legal-collection     = COLL             "@" xdi-name COLR
or something like that...

First, the legal context symbol is now +, not @. And second, the collection of entities that are purely identified as legal authorities is indeed just identified as [+]. The same is true for the collection of personal authorities, [=], and the collection of general authorities (things), [*].

The reason that no XDI name is allowed after these context symbols because, with authority context symbols, it is the symbols themselves that provide the type of the collection. Any XDI name after the symbol, e.g., +neustar, represents an authority instance, and by definition you can't have a collection of an instance, you can only have a collection of a set of members of the same type.

Here's another way to put it:
  • [=] is the collection of all personal authorities, i.e., entities of type "person"
  • [+] is the collection of all legal authorities,  i.e., entities of type "legal"
  • [*] is the collection of all general authorities, i.e., entities of type "general" (anything that has independent identity)
  • [$xxx] is the collection of all entities of type $xxx (defined by the XDI TC)
  • [#xxx] is the collection of all entities of type #xxx (defined by community consensus)

On Sep 15, 2014, at 9:05 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:

On Mon, Sep 15, 2014 at 6:06 PM, Le Van Gong, Hubert <Hubert.LeVanGong@neustar.biz> wrote:
Andy recently mentioned a bug in the XDI graph editor where collections are not represented using a diamond (attribute).

As I'm trying to determine the appropriate pattern for collections, I started reading the XDI ABNF and came up with some questions: what type of collections *must* be represented as an attribute?
For instance, should we represent an authority-collection (i.e. a person-collection or a legal-collection) as an attribute?

Hubert, there are only two types of collections: entity collections and attribute collections. Authorities (persons, legal, general) are just subtypes of entities. The existing ABNF may not make that clear enough, which leads us to...

Also, can someone confirm https://wiki.oasis-open.org/xdi/XdiAbnf is up to date?

It's not. I just put the most recent top-level ABNF at the top of the ABNF Discussion page. Hopefully this makes it much clearer that there are only entity collections and attribute collections. The former should be represented in the visual graph notation as filled circles; the latter as filled diamonds.



Hubert A. Le Van Gong
Distinguished Engineer, Technology Foundry
San Jose, CA 95129
email: hubert.levangong@neustar.biz

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