[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [orms] Selection of Elements
> It is OK to make them globally unique if they are scoped to that transaction and not correlatable. > Yes, I assumed that they were scoped and it could be transaction sensitive and transient when I wrote that example. The URIs in both <Subject> and <Assertion> are application specific, right? So, I didn't specify what format it should be. I just don't know how similar elements are defined in other specs. I am reading them from the coverpage. http://xml.coverpages.org/xmlApplications.html I thought that just saying "it is anyURL" is good enough for this spec. I am expecting that profiles based on this spec will be defined by many different players. That will define its context(namespace), types in elements, and specific XML schema for each element, so forth. Tatsuki (4/29/10 5:50 PM), John Bradley wrote: > It is OK to make them globally unique if they are scoped to that transaction and not correlatable. > > But I think you will want to differentiate that case from the case where the subject is named by the URI eg http://Google.com > > If I want Google's reputation. > > Even if they are all URL sometimes you need more information. > > John B. > On 2010-04-29, at 8:41 PM, Tatsuki Sakushima wrote: > >> 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 >> --------------------------------------------------------------------- >> 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]