RE: [rights] [rights-requirements] Some thoughts on "Core" requirements

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

Without quoting Parama's message, I wanted to say that 

1. I agree with his working definition of "core" 100%. I even used the
C/printf analogy myself in a recent discussion with Hari. 

2. There's still a problem, though: saying "the issues that some consider to
be core aren't really core" isn't enough; those issues still need to be
addressed. If it's not time to address them yet, then it's time to put
together a specific plan for addressing them. I have an idea for doing this,
but first I want to discuss the real root of the problem--a "core" problem
in the spec, (as opposed to a problem with the core spec) that will lead to
many other problems besides this one. 

To summarize:

- The XrML spec does not yet specify what it means to conform to the spec,
so people don't know what to expect of XrML processors. 

- This can lead to many problems. A current one is that those seeking
assurance that XrML-based DRM processors will address certain basic public
interest concerns have no means to put these capabilities in place as part
of XrML requirements.

- To head off this and other problems, the spec needs a conformance section
sooner rather than later. To address this particular problem, the members
could vote to require that support for a BasicRights extension for an XrML
processor is necessary for a processor calling itself XrML-compliant. (Note:
the name BasicRights is off the top of my head, and its architectural
role--whether it's an extension or a profile or what--still needs to be
worked out.)

Longer discussion:

A former employer of mine once wrote a program that would parse well-formed
XML into data structures that could be manipulated in memory--as long as
there were no entity references in the input. I told him that, despite his
claims, he hadn't written an XML parser. Chapter 5 of the XML Recommendation
explains the responsibilities of a program calling itself an XML parser, and
if the string &foobar; didn't send his program off looking for the
declaration of a foobar entity, then he hadn't fulfilled all of those
responsibilities yet.

I can't find anything in the core or standard extension parts of the XrML
2.1 specs that defines conformance. If party A is going to be sending
digital works with XrML licenses to party B, and they figure out some subset
of XrML that serves their needs, and party B's processor only pays attention
to the agreed-upon subset of XrML, is party B using a processor that
conforms to the spec? We can't say. I can't point them to a specific part of
the spec, as I could point to Chapter 5 of the XML Rec when I told my former
employer that his program wasn't a conformant XML processor. What happens if
party C sends material to party B with XrML licenses that use parts of XrML
outside of the A-B subset? B had assured C that his processor was
successfully handling XrML licenses, but it can't handle C's licenses. 

According to http://www.oasis-open.org/committees/rights/, our number 7
deliverable is "Definition of conformance criteria." Perhaps this needs to
be bumped up in priority and in our schedule. Doing so will make it much
easier to build the addressing of public interest concerns into the spec. I
don't believe that these should go into the core. I do believe that they're
important enough that they shouldn't fall into the category of "we can get
to that later." I think it's clear that we need to define an architectural
role for an XrML-based way to express public interest concerns, and if a
committee member proposes that support for this extension/profile be
included as a requirement for all conformant XrML processors, then we should
vote on it. The conformance policy could be as simple as "Conformant XrML
processors will support the entire core specification as well as the
standard and BasicRights extensions to the core." 

If the concept of XrML conformance is defined somewhere and I just missed
it, I still believe that the possibility of making support for a BasicRights
extension part of that conformance could be a way to address the problems
under discussion. If it does make sense as a profile, the work could be an
outgrowth of the profiles subcomittee. If not, a subcommittee to address
XrML's approach to basic public interest issues is still worth forming, as
long as they have the assurance, in writing, that something specific will be
done with their work product.

One more note: just because something doesn't belong in the core doesn't
completely remove it from core concerns; the implementation of an important
extension feature may require changes to the core. Java doesn't support file
I/O in its core, but provides the means to implement it. JavaScript, however
(or more specifically, Ecmascript) does not provide a basis on which to
support file I/O, with good reason, and demonstrates how cores don't always
support everything necessary. So we can't just forget about potential
extension requirements as we work on the core.

Bob DuCharme
Consulting Software Engineer, LexisNexis
Data Architecture, Editorial Systems and Content Engineering