[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights-requirements] FW: [Fwd: Core vs. Non-Core]
[forwarded on behalf of Hari] Hi Patrick: Again my apologies...you should have been able to send this to the list last week. I am copying OASIS in this post to try to resolve. I am having problems sending information in myself this morning and Karl has been helping me by forwarding my postings... Thanks for your note... I will try to answer some of your questions/points by clipping from your original email...: From Patrick: It appears to me (and this may be obvious to everyone else) that Hari's parsing of the requirements into core vs. domain reflect an a priori acceptance of XrML 2.1 as it stands now. Is that a correct reading? Hari: The charter states (http://www.oasis-open.org/committees/rights/#charter): 2. Use XrML as the basis in defining the industry standard rights language in order to maximize continuity with ongoing standards efforts. With that pointed out, the requirements were parsed using the notion of a core, standard extension and domain extension. This architecture was actually pointed out in the Reuters requirements set. Also, as Thomas DeMartini stated in a previous email (I can't seem to access the list serv to give you a pointer from my office but it was posted on 08-22-02): Thomas DeMartini writes : -------------------------------- ... What this means is that we want to get something out to the world, a set of requirements that we all agree on. There are several things that this does not mean. a) This does not mean that input for requirements has been closed. b) This does not mean that XrML v2.1 satisfies all the requirements in requirements v1.0. c) This does not mean that XrML v2.1 does not satisfy all the requirements in requirements v1.0. d) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.0. e) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.0. f) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.1. g) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.1. What it does mean is that we have a set of requirements we call 1.0, and we publish it as a document that we think we can go forward with, and that if there are any people who would like to use the spec that do not see their requirements there we would expect their feedback. -------------------------------- From Patrick: I would rather develop the requirements (BTW, are there any internal requirement documents from ContentGuard reflecting the requirements for XrML that can be shared with the group?) and then evaluate XrML in light of those requirements. Hari: One of the customers of the Requirements documents is the Specification SC which will evaluate the requirements and provide a technical response using the current baseline. This is the evaluation step that you highlighted and was also mapped out when we started this process. With respect to the ContentGuard requirements, ContentGuard submitted a 50+ page document to the ISO/JTC1 (MPEG) and OeBF processes which have subsequently submitted their requirements to our TC. Hope this answers your points and thanks again for your help... Regards, Hari -----Original Message----- From: Patrick Durusau [mailto:pdurusau@emory.edu] Sent: Tuesday, August 27, 2002 2:11 PM To: Hari.Reddy@CONTENTGUARD.COM; robin@isogen.com Subject: [Fwd: Core vs. Non-Core] Hari, A message I posted last week that appears to have not made it to the list. Thanks! Patrick -------- Original Message -------- From: - Wed Aug 21 16:57:49 2002 X-Mozilla-Status: 0003 X-Mozilla-Status2: 00000000 Received: from desdemona.cc.emory.edu (desdemona.cc.emory.edu [170.140.204.1]) by enceladus.cc.emory.edu (8.8.8/8.8.8) with ESMTP id NAA16017 for <pdurusau@mail.service.emory.edu>; Wed, 21 Aug 2002 13:49:56 -0400 (EDT) Received: from imf01bis.bellsouth.net (mail201.mail.bellsouth.net [205.152.58.141]) by desdemona.cc.emory.edu (8.10.2/8.10.2) with ESMTP id g7LHoGa10464 for <pdurusau@emory.edu>; Wed, 21 Aug 2002 13:50:16 -0400 (EDT) Received: from bellsouth.net ([65.81.145.8]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020821175149.QZXU12335.imf01bis.bellsouth.net@bellsouth.net>; Wed, 21 Aug 2002 13:51:49 -0400 Message-ID: <3D63CEEF.8030102@bellsouth.net> Date: Wed, 21 Aug 2002 13:33:35 -0400 From: Patrick Durusau <pdurusau@bellsouth.net> Reply-To: pdurusau@emory.edu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 CC: rights-requirements@lists.oasis-open.org, rights@lists.oasis-open.org Subject: Core vs. Non-Core References: <3D63C61D.3090408@bellsouth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greetings, First, let me say that during the very brief time I have been associated with this group that I have rarely seen anyone work as hard as Hari in terms of collating the various requirement documents. I am working through the core document more carefully than my first read and wanted to check something that came up in this mornings conversation. It appears to me (and this may be obvious to everyone else) that Hari's parsing of the requirements into core vs. domain reflect an a priori acceptance of XrML 2.1 as it stands now. Is that a correct reading? If we are submitting requirements for a rights expression language, I would expect the next step to be determining a set of requirements for such a language. Once those requirements have been determined, then and only then would we turn to either constructing such a language or evaluating a candidate for such a language, such as XrML 2.1. I don't doubt that ContentGuard and probably Hari personally have saved the group months of time in the standards process by their development of XrML but, I don't think the classification of requirements by the standard that hopefully will be seen (and used) as meeting those requirements (not the other way around) is very helpful. I would rather develop the requirements (BTW, are there any internal requirement documents from ContentGuard reflecting the requirements for XrML that can be shared with the group?) and then evaluate XrML in light of those requirements. I don't think that would take any longer than the present process and would make the mapping of requirements to XrML a little easier to follow. Patrick -- Patrick Durusau Director of Research and Development Society of Biblical Literature pdurusau@emory.edu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC