OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

orms message

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


Subject: Re: [orms] Selection of Elements


Hi John,

Thank you for the comment. I intentionally made the structure of the document flat.
So I added the type attribute in <Subject>. But I am not really convinced yet. 

> Sometimes the subject may be ephemeral if it is about the subject of some outer assertion.
> In the child case you have a null subject.  If you define a local NameIDFormat then you could call it Child1 to differentiate it from other child elements.

I supposed to put an identifier into the child <Subject> in the example, but I forgot it.
My understanding of <Subject> is that the element contains a globally unique identifier
for itself. So, even though the sub reputation document inside the parent document, 
it must have an identifier.

I forgot the value in the child <Subject> by mistake, but should we consider a nil case?

BTW, for an assertion, I made the <Assertion> element. It can change without changing <Subject> id (id for this document). It just need to update <Date> if <Date> is for updated. 

Tatsuki

(4/29/10 4:49 PM), John Bradley wrote:
> That is logical.
> 
> You may want to have a <NameIDFormat> element.
> 
> Sometimes the subject may be ephemeral if it is about the subject of some outer assertion.
> In the child case you have a null subject.  If you define a local NameIDFormat then you could call it Child1 to differentiate it from other child elements.
> 
> The subject may be a URI or some other custom format.
> 
> John B.
> 
> On 2010-04-29, at 6:55 PM, Tatsuki Sakushima wrote:
> 
>> I have been thinking how to make ORMS simple and accommodating as many use cases as possible.
>>
>> -----
>>
>> 6.1 Element <ReputationBundle>
>> The <ReputationBundle> element can contain two or more <Reputation> elements to optionally make a group of reputation instances.
>>
>> 6.2 Element <Reputation>
>> The <Reputation> element encapsulates the entire reputation document. It contains the following attributes and elements:
>>
>> <Subject> [One]
>>  Identifier of the reputation described by this document.
>>
>> <Context> [One]
>>  Context namespace. Identifier of context namespace of the reputation described by this document.
>>
>> <Assertion/Reputee> [Zero or One]
>>  Identifier of the assertion of the entity or the entity itself evaluated in this document.
>>
>> <Score type="http://amaama.co.jp/reputation/score/products/books/fivestar";> [One or More]
>>  The reputation score. 
>>
>> <Date type="http://amaama.co.jp/reputation/date/updated";> [Zero or More]
>>  The date data described by this document.
>>
>> <ds:Signature> [Zero or More]
>>  This XML Signature, included from the [XML Signature] schema, protects the integrity of the document, as described in Section ?. 
>>
>> -----
>>
>> Here are some examples based on the definition above:
>>
>> Example 1 "Simple"
>>
>> <Reputation>
>> <Subject>http://amaama.co.jp/literature/auther/hmurakami/title/1Q84#TCDVSuG6grhyHbzhQFWFzGrxIPE</Subject>
>>  <Assertion>http://kodansha.co.jp/literature/hmurakami/1Q84</Assertion>
>> <Context>http://amaama.co.jp/reputation/score/products/books</Context>
>> <Score type="http://amaama.co.jp/reputation/score/products/books/fivestar";>4.3</Score>
>>  <Date type="http://amaama.co.jp/reputation/date/updated";>1970-01-01T00:00:00Z</Date>
>>  <Date type="http://amaama.co.jp/reputation/date/created";>1970-01-01T00:00:00Z</Date>
>> </Reputation>
>>
>> Example 2 "Bundle"
>>
>> <ReputationBundle>
>>  <Reputation type="parent">
>>    <Subject>http://amaama.co.jp/literature/auther/hmurakami/title/1Q84#TCDVSuG6grhyHbzhQFWFzGrxIPE</Subject>
>>       <Assertion>http://kodansha.co.jp/literature/auther/hmurakami/title/1Q84</Assertion>
>>    <Context>http://amaama.co.jp/reputation/score/products/books</Context>
>>    <Score type="http://amaama.co.jp/reputation/score/products/books/fivestar";>4.3</Score>
>>       <Date type="http://amaama.co.jp/reputation/date/updated";>1970-01-01T00:00:00Z</Date>
>>       <Date type="http://amaama.co.jp/reputation/date/created";>1970-01-01T00:00:00Z</Date>
>>  </Reputation>
>>  <Reputation type="child">
>>    <Subject></Subject>
>>    <Link rel="http://amaama.co.jp/reputation/score/1.0"; href="http://amaama.co.jp/reputation/user/userida";>
>>    ---whatever---
>>  </Reputation>
>> </ReputationBundle>
>>
>> Comments are welcome.
>>
>> Tatsuki
>>
>> (4/22/10 1:40 PM), Tatsuki Sakushima wrote:
>>>> From the conversation yesterday, I thought that selecting basic elements we are going to put in ORMS might accelerate a spec work. Here is the list of current proposal from Nat a few years back. Probably these need updating: 
>>> ?.1 Element <ORMS/Reputation>
>>> ?.2 Element <SubjectID>
>>> ?.3 Element <RSPID>
>>> ?.4 Element <AssertionID>
>>> ?.5 Element <RequesterID>
>>>
>>> Issue 1. Too many IDs might be confusing. Can we simplify? 
>>>
>>> ?.6 Element <DisplayScore>
>>> ?.7 Element <Score>
>>> ?.8 Element <ConfidenceInterval>
>>> ?.9 Element <Distribution>
>>> ?.10 Element <Mean>
>>> ?.11 Element <StandardDeviation>
>>> ?.12 Element <SampleSize>
>>>
>>> Issue 2. Still need to discuss how we can accommodate common use cases captured in the RealLifeExmaples Wiki. 
>>>
>>> ?.13 Element <Date>
>>> ?.14 Element <StartDate>
>>> ?.15 Element <EndDate>
>>>
>>> Issue 3. Also many date related elements leads to confusion.
>>>
>>> Any comment?
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
> 


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