RE: [rights-examples] ln00x use case discussion

["DuCharme, Bob (LNG)" <bob.ducharme@lexisnexis.com>]

(I attempted to quote the last one as concisely as possible to give context
to my comments without making this too long. ">>" starts my original
questions and ">" Thomas's responses.)

>>xrml2core.xsd declares an element called "xml," but 2.3 of the XML
>>recommendation reserves the use of any names beginning with XML. From
>>an XML 1.0 viewpoint, I suppose you could say that the xrml2core name
>>is actually spelled "r:xml", but it's something to keep in mind.

>i remember checking this before but somehow thought it only applied to
>attribute names (possibly because element default is set to qualified,
>as you point out).  

Production 45 of the XML Rec shows that an element type name must be a Name,
and according to section 2.3 of the Rec "Names beginning with the string
"xml", or any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are
reserved for standardization in this or future versions of this
specification."

>perhaps it makes sense to change the names to be
>more environment-friendly.  if i forget, remind me to submit a CR once
>the CMP gets approved.  or would you do the honor of the first one? 

Sorry, neither of the acronyms ring a bell.

>>1. (Use case ln001). If I want to say that all customers of customer
>>class c10012 may have a particular right, what's the best way to do
>>this? The XrML idea of the principal, according to the technical
>>overview, "must be resolved to a single party."

>Actually, you might read that as "single party of 4" or something like
>that.  The singleness of the party is only in that using the
>authentication means of the principal the computer cannot distinguish
>the party from the party.  For instance, if the party is username
>bobducharme@lexisnexis.com, that is a "single party" as far as the
>computer can tell.  If you share your password with three different
>people, that is still one party.  Four people, but one party.  Kinda
>weird, but the only way it works.  

>>Isn't there something more

>(you mean less?) 

>>general than Property but less 

>(you mean more?) 

>>general than coupling possessProperty with something we make up
>>ourselves to express this?

No, I meant more general than Property when I thought that "party" referred
to a specific person and I wanted to assign rights to a class of people. I
wanted something less general than coupling posessProperty with something we
make up ourselves because the ability to make up something on your own and
plug it in is a pretty generalized solution, and I wanted something more
specific.

>Actually, the cool thing about possessProperty is that it works using
>the XrML notion of equality.  What this means is that you can have an
>implementation (that knows nothing about what foo:customerClass=c10012
>means (and might have even been written years before foo:customerClass
>was invented)) still be able to successfully process those licenses by
>using other possessProperty licenses which bind certain principals to
>that class.
> 
>Or maybe you are getting at the fact that it is perhaps a pain to
>write and propogate (probably the bigger headache) a schema for each
>person who wants to do something like customer class.  There have been
>several attempts at defining a generic property such as securityLevel
>and group and subscription and etc, but none seem to be truly generic.
>One thing we might try is some sx:class of type xsd:anyURI.  

Or sx:principalClass to represent a class of principals. 

>This way
>you can assign people to certain classes using the class element and
>all you have to really do is come up with a URI to indicate your
>class.  ?

e.g. http://www.lexisnexis.com/whatever/c10012, I suppose. I'm actually not
interested in assigning people to classes. When a content provider sends
something to an aggregator (the situation for which we need a DRM language)
specific individual users are not an issue; classes of users are. Perhaps
this ability should shake out as a new requirement for the spec. 

>>2. (ln004) Is there XrML markup to say "usage parameters of this
>>resource are described in the license with the ID 'c12345', whether
>>that license is expressed as XrML markup or as a hard copy contract"?

>This one is tricky, in a way.  Let us, for a moment, assume that we
>have a bunch of XrML licenses and English licenses floating around.
>The XrML licenses indicate inside of them what content they apply to.
>The same goes for the English licenses.  

Actually, it makes more sense for my purposes to turn this around: the XrML
licenses don't indicate what content they apply to; the content indicates
which licenses apply. This is what I was trying to express in my use case. 

>Now, if somone knows what
>content they have, how do they figure out what licenses apply?

Because the content says which licenses apply, if only by specifying an ID
of the license. The license only specifies the right(s) and the
condition(s). Note that I didn't have any question about ln005--the
following seemed to work fine:

  <grant>

    <dcx:play/>

	 <sx:territory>
	   <sx:location>
		  <sx:country>US</sx:country>
		</sx:location>
	   <sx:location>
		  <sx:country>CA</sx:country>
		</sx:location>
	   <sx:location>
		  <sx:country>MX</sx:country>
		</sx:location>
	 </sx:territory>

  </grant>

To sum up, I see the following as a viable model for what we need to do:

- a collection of licenses that pair up rights and conditions (with, I
suppose, some conditions describing classes of customers that users must
belong to in order to be granted the rights, perhaps using a principalClass)

- content that points at existing licenses, perhaps using the license
elements licenseId attribute.

Does this seem too far off from the general XrML approach to you? 

thanks,

Bob