From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, February 22, 2008
8:40 AM
To: higgins-dev-bounces@xxxxxxxxxxx
Cc: 'Higgins
(Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] Data
Model (yet again)
I
think we agreed that we wanted to allow sub-typing for at least Node types,
attribute types, and attribute value types (we never talked about Context types
in this regard)
Yes, any “real” context instance will
want to define Node subclasses, attribute types, data ranges (aka attribute
value types). The model can’t preclude subclassing Context itself, though I don’t
think IdAS has any special support for that.
But
even if we already had the notion of sub-typing built in everywhere, I don't
understand the second part of your complaint: "makes you look at each
instance to determine it's type". Each instance of what, Nodes,
Attributes, AttrValues, or NodeModels, AttrModels, and AttrValueModels?
Jim
>>> Anthony Nadalin
<drsecure@xxxxxxxxxx> 02/21/08 9:34 PM >>>
1. The data mode is an un-typed mode, (no sub-classes)
makes you look at each instance to determine its type, this is not suitable for
data mining and creating graphs of the data charateristic.
3. Yes
Anthony Nadalin | Work
512.838.0085 | Cell 512.289.4122
"Paul Trevithick" ---02/21/2008 04:26:08 PM---1.
I don’t understand.
|
From:
|
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
|
|
To:
|
"'Higgins \(Trust Framework\) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Date:
|
02/21/2008 04:26 PM
|
|
Subject:
|
RE: [higgins-dev]
Data Model (yet again)
|
1.
I don’t understand.
2. I was
informed today on the call that I missed some emails on the higgins-dev list in
the past week on that topic. From what folks on the call said: (a) they agree
with you (b) apparently there is some rough consensus on what to do about it.
I’ll learn more as I re-read the higgins-dev list.
3. Hmm. Let
me see if I understand your issueâ€|. Given Node (N1) that has two Node
Relations emanating from it, e.g one pointing to N2 and another pointing to N3,
then are you saying that we’re lacking a way to “tag� or otherwise
distinguish between these two Node Relations?
BTW, here are some other things that the data model is
missing off the top of my headâ€|
1. Access
control policy _expression_: We agreed on the call today that we’ll schedule a
dedicated call about this in the next week. I’ll send links to a proposal for
a very rudimentary access control approach along with the meeting invites.
2. As
discussed at the F2F in Provo:
the ability for the model to express policy information at the IdAS/CP/data-model
level that today can only be expressed by an STS. The use case that we want to
support is a “recursive� case where someone layers IdAS over, say, an
LDAP data store on the one hand (that’s easy), and context provider that is “fronting�
an STS on the other hand. The problem is that the IdAS consumer can’t query
for the STS’s policy.
3. Other
thingsâ€| (e.g. how to declare Node classes as “closedâ€?)â€|etc.
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Anthony Nadalin
Sent: Thursday, February 21, 2008 4:54 PM
To: 'Higgins (Trust
Framework) Project developer discussions'
Subject: [higgins-dev] Data Model (yet again)
So I
don't feel like we are quite there yet for several reasons:
1. This is a runtime
data model, there are not yet any tools that can create the graphs that I think
folks might need
2. There still is no
direct way for one node to reference a specific attribute or specific type of
attribute in a different context/node
3. When using
relations there is now way to tell what relation we are really talking about
Anthony Nadalin | Work 512.838.0085 | Cell
512.289.4122_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
