Re: [orms] Current issues [5/5/2010]

[Tatsuki Sakushima <tatsuki@nri.com>]

Thank you Nat,

I agree with the definition but it is not really machine-friendly.
I was wondering what a value the element would have.
If I follow your definition, it would have any string as the value.
Also I was thinking like AssertionID in SAML, it was not really
useful since we have <Subject>. (Do we evaluate SAML assertions?)

I intestinally avoid using a wrapper and a group element.
IMHO, it causes complexity and makes a spec and data hard to read. 
Also I try to follow the principles I set.
If <Assertion> just groups some elements, I just don't know
what good it does for machines.

I guess that we need more examples of how to use assertions
in order to come up with the definition.

Tatsuki 

(5/5/10 7:42 PM), Nat Sakimura wrote:
> Assertion, IMHO, is a statement. For example,
> "Nat Sakimura is a good father at home" is an assertion,
> where "Nat Sakimura" is the subject and "is a good father"
> is the Criteria, and "at home" is the Context.
> In another word, subject, criteria, context are the variables in Assertion.
> It might be easier to think of it as a wrapper element of subject,
> context, and criteria.
> 
> =nat
> 
> (2010/05/06 2:52), Tatsuki Sakushima wrote:
>> I summarize current issues: 
>>
>> ----
>> 1. Definition of Subject, Assertion and Context
>>   -Definition of each
>>   -How to use each element? (function)
>>
>> 2. How to use <Assertion>
>>   -In a very simple case, <Subject>, <Context> and <Score> are enough.
>>   -When do we use <Assertion>? (specific criteria)
>>
>> 3. Nessecity of the document id
>>   -What if <Subject>s in parent and child are the same?
>>   -This document id and Subject id may not be the same (but could be consolidated). 
>>
>> 4. How to organize <ReputationBundle>
>>
>>   Use cases:
>>     1)In the same file
>> 	2)Separate files but handled locally in the same machine
>> 	3)Separate files handled in a distributed way
>>   -Anything else?
>>
>>   
> 
>