[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [rights] [rights-requirements] Some thoughts on "Core" requirements
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC