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

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

[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