[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights-examples] ln00x use case discussion
After working on some XrML markup to represent my use cases, I sent some questions in a private e-mail to Thomas. I'm posting my questions and his responses here so that we can continue the discussion on this mailing list. I'll be posting my responses to his comments shortly. Lines preceded by ">" show my original questions and comments. Bob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Now that I'm trying to do XrML versions of my own use cases, I have >some questions. First, a few notes: > >The xsd:annotation documentation in the schemas are very well done. > >Xerces Java 2.0.1 didn't do a very good job of parsing the examples >that I'm working on against the schemas, but I downloaded 2.0.2 today >and it does much better. Its dom.ASBuilder utility is great for >checking documents against schemas or even just checking the syntax of >the schema itself. > >For the purposes of my attempted markup, I just created a variation of >the cx namespace called dcx (demo content extension) to check my >examples to make sure that they parsed. o.k. i have also this morning created a schema that reflects some of the most recent MPEG decisions to date. if you can get by with dcx, though, until July 26th, that would be great. >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). 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? >(Numbers refer to the numbers assigned to each use case in an earlier posting to the examples list.) > >My first four questions: > >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 email@example.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. Hopefully one of these days someone will come up with an authentication means by which there are only one-person parties. Retinal scans maybe? ...if that's the case, then maybe hopefully not, depending on where you stand on the ethics... > An alternative would be to not specify a principal at all and to >somehow express "customerClass="c10012" as a Condition, but the >closest example I can find in the CG Example Use Cases document is >4.10, in which a possessProperty element is contained by the same >element as a sony:sonyClubMember element. 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? 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. 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. ? >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 will be an important capability for us as we make the transition >from manual enforcement of grant parameters (e.g. representatives of >two parties hammer out a contract, tech guy on receiving end does >whatever is necessary to enforce those parameters). In a transitional >stage, before the sender specifies all parameters using XrML, some >sort of ID would be assigned to the contract and content metadata >would refer to it using that ID. 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. Now, if somone knows what content they have, how do they figure out what licenses apply? The trivial example is a search through all of the licenses checking if each one, in turn, applies and then returning all matches. A more sophisticated solution might be to index the licenses in a database-like fashion so that one can more efficiently arrive at the list of licenses that apply by running a query. Another step might be to store the output of such a query along with the content so that even the query doesn't have to be run. The advantage of this last step is greater speed; the cost is the list is no longer dynamic as new licenses are created and old licenses expire. And, as you point out, another advantage of the last step is to aid transition. Anyway, the reason I present it this way is to set up my answer to your question "is there XrML markup to say 'usage parameters of this resource are described in the license with ID "c12345"'". At the license level, this answer is "it is out of scope". As you can see from the discussion above, it is the XrML markup that says what resource the license applies to. It is an exercise in indexing that allows this information to be viewed most efficiently from another direction. (Relational databases are very useful for this kind of thing, but are not required.) Such indexing exercise can chose to index English licenses as well as XrML licenses (there is no constraint on such indexing); the result would be a way to look up all licenses that apply. And, if you identify the licenses with URL URIs in your indexing, there is nothing wrong with updating an English license with an XrML license at the same URL. At the condition level, the answer is "sort of but not yet really". If you're interested, I can give you the "sort of" later, but its probably not what you want anyway, so I won't explain it here. Rather, I'll take a shot at what I think you might be asking for and then say that we don't have it yet, but that I don't see why we shouldn't have it in the future. Anyway, here goes: If the transitional stuff you are talking about is not at the full license level, but rather a hybrid of XrML permissions set against English conditions, this can be done using a hypothetical new condition called "EnglishConditions" which contains a bunch of free text. The Principal/Right/Resource arms of the grant can be in XrML to identify who can do what to what, but all the terms and conditions are still in English. <grant> <keyHolder licensePartIdRef="CompanyA"/> <mx:copy/> <digitalResource licensePartIdRef="TheText"/> <sx:EnglishConditions>Pay $1 per copy to the author.</sx:EnglishConditions> </grant> and/or <grant> <keyHolder licensePartIdRef="CompanyA"/> <mx:embed/> <digitalResource licensePartIdRef="TheText"/> <sx:EnglishConditions>The author is credited in the text of the work into which this work is embedded.</sx:EnglishConditions> </grant> and/or <grant> <keyHolder licensePartIdRef="CompanyA"/> <mx:edit/> <digitalResource licensePartIdRef="TheText"/> <sx:EnglishConditions>Spelling edits that do not change the meaning only.</sx:EnglishConditions> </grant> >3. (ln003) I checked all the elements in xrml2core, xrml2cx, and >xrml2sx that can substitute for r:condition (i.e. that specify it as a >substitionGroup) and didn't see any that looked like candidates for >linking an isPartOf relationship to a rendering condition. Do you have >any suggestions? MPEG has made significant progress in addressing these kinds of containment issues. An element they have come up with is diPartOf, which explains a part of relation, but doesn't have quite the same nuances as what you are looking for. The difference between diPartOf and isPartOf is that diPartOf only requires that, say, an image is part of something else. There is no requirement that the image actually be *viewed as part of* that something else. A little backround on "di". Di is short for Digital Item, which is MPEG's way of describing multi-resource media. Take, for instance, and html page that has an image. It is possible to grant rights to play the image once. It is also possible to grant rights to play the html page (without the image) once. Someone who wants to view the html page with the image inline will have to use up both rights. In some cases, this is actually what the content owner intends. In other cases, the content owner wants to specify that playing the *Digital Item* (the combination of the html page and the image) can only be done once (regardless of whether the user has "load images" enabled that one time or not). What MPEG hasn't yet addressed is a constraint requiring the html page to be viewed in conjunction with the image. The reasoning behind this goes as follows. It seems that the intent of requiring this is not so much to require actually computer things to happen as require the user to perceive something. That said, many things stand in the way of the user perceiving something. For instance, perhaps someone's instant messaging software is always-on-top the browser where the image is supposed to go. Or, in the case of video+audio, perhaps someone has their speakers turned off or not connected to the sound card. Or, perhaps the person is deaf. In cases where the reason for wanting the user to perceive something is to warn them, it makes more sense to have a condition called "ConfirmWarning" or something that allows the user's software to get that confirmation from the user however the user can give it. (For instance, it could be a popup with an o.k. button, but if the user can't see, it might be a spoken prompt.) In cases where the reason is solely for presentation, it was deemed that the Digital Item approach was enough. While granting the right to play a Digital Item (such as the html + image) doesn't require the parts to be viewed together and in the presence of one another, the software that processes Digital Items will know that they are intended to be one unit and should make a reasonable effort to present them as such. Another line of reasoning, also supporting the same conclusion, goes like this: when someone has the right to play an image, the presentation may involve the whole image or any part thereof. Similarly with an audio recording, a piece of text, or a video. Thus, when we have composite media such as html+image it stands to reason that the right to play the item means that the presentation could be the entire item or any part thereof. Since the image is just one part of the item, there is no constraint that the image cannot be played by itself. All of that said, this explains why r, sx, and mx do not deal with this problem. If there is some group of people where the problem is of vital importance (so much so to outweight the costs), then there should be nothing in XrML preventing these people to get together and define what this problem actually is and what it means to systems which support it. For instance, a simple solution to some problem might be a condition called something like "presentedInEntirety". When applied to an html page it means the browser would have to put it up and scroll through it all for the user. When applied to an image, it means the viewer would have to put it up and scroll through it for the user. When applied to an item that consists of html+image, it would mean the browser would have to put them up together and scroll through them both. I'm not familiar with a problem that has that solution, but it is an example of a problem I might not know about. Most of the problems I've seen have eventually worked down to the solution MPEG has, and I suspect that is the case here, but I'd need a fuller understanding of the problem to be sure. >4. (ln006) The renderer element "Identifies the device that can be >used to render a work. Used with render rights" and has principal as a >child element. Principal doesn't have any children, and the elements >that can substitute for it are allPrincipals and keyHolder. How would >I specify that a document can only be rendered if it is done so on a >device of class dev001? Lets suppose each device has a key and that we want to allow it only to be rendered on one particular device. Then the grant would look like this: <grant> <keyHolder> <info> ...fill in user key here... </info> </keyHolder> <mx:play/> <digitalResource> ...fill in resource here... </digitalResource> <mx:renderer> <keyHolder> <info> ...fill in device info here... </info> </keyHolder> </mx:renderer> </grant> Now, if we want to do this for any renderer that authenticates with any key, we use an unconstrained variable (lets call it "device") like so: <grant> <forAll varName="device"/> <keyHolder> <info> ...fill in user key here... </info> </keyHolder> <mx:play/> <digitalResource> ...fill in resource here... </digitalResource> <mx:renderer> <keyHolder varRef="device"/> </mx:renderer> </grant> Now, if we want to constrain this only to devices with keys of class dev001, we add the constraint on the variable, like so (using the hypothetical sx:class element I mentioned earlier): <grant> <forAll varName="device"> <everyone> <sx:class>urn:someOrg:deviceClass:001</sx:class> <trustedIssuer> <keyHolder> <info> ...fill in here the key you trust to certify device keys as belonging to this class... </info> </keyHolder> </trustedIssuer> </everyone> </forAll> <keyHolder> <info> ...fill in user key here... </info> </keyHolder> <mx:play/> <digitalResource> ...fill in resource here... </digitalResource> <mx:renderer> <keyHolder varRef="device"/> </mx:renderer> </grant> or (equivalently) (if you prefer the prerequisiteRight style of constraining the device): <grant> <forAll varName="device"/> <keyHolder> <info> ...fill in user key here... </info> </keyHolder> <mx:play/> <digitalResource> ...fill in resource here... </digitalResource> <allConditions> <mx:renderer> <keyHolder varRef="device"/> </mx:renderer> <prerequisiteRight> <keyHolder varRef="device"/> <possessProperty> <sx:class>urn:someOrg:deviceClass:001</sx:class> <trustedIssuer> <keyHolder> <info> ...fill in here the key you trust to certify device keys as belonging to this class... </info> </keyHolder> </trustedIssuer> </prerequisiteRight> </allConditions> </grant> Hope this helps? Thanks, Thomas.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC