RE: [rights] Core, Standard Extension,Conformance and Profiles - A non political discussion

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Title: RE: [rights] Core, Standard Extension, Conformance and Profiles - A non political discussion

This is good discussion.  It is good to use words other than "core" and "standard extension" in the profiles, to avoid confusion with the spec.  "Base" is good, as long as the connotations are intended.  Each heading we come up with should have some one-sentence description or so that says what it is supposed to be better than the one-word heading can.  Also, I encourage people not to shy away from using headings like "A", "B", and "C" if it makes sense to do so.

Perhaps one of the first things we need to do is decide what profiles we need.  At the F2F three options were discussed:

1. Define best practices for writing profiles and also write profiles for various industry sectors.
2. Define best practices for writing profiles and then write a couple example profiles which we do not envision actually being used.

3. Just define best practices for writing profiles.

I actually advocate that we do something between 1 and 2 at this time.  The reason I don't want to do #1 is because, in order to do #1, we need to gather a large cross-section of the players in a particular industry.  Coming up with industry profiles is at least a three-pronged effort: technical, business, and political.  The technical aspect needs to be there to evaluate the implementation cost of including or excluding certain expressions.  The business aspect needs to be there to negotiate support among different industry players, as in "if you support this, i'll support that, etc."  The political aspect needs to be there to make sure that the ultimate profile arrived at is going to be usable in the political environment.  I think it will be hard to gather this large cross-section of players in the near term.  Usually, this people will at least want to see a spec before they participate.  They may even prefer to wait until we finish with #3 and #2.

I don't think we can do #3 all by itself, because we need to at least do #2 to validate that what we wrote in #3 is correct and useful.

#2 seems to be a good start.  We might be able to go a little further than #2, though, by defining some profiles of the core that we expect can be reused in the industry profiles.  For instance, one profile might say that all expressions with licensePartIdRef and varRef are excluded.  This saves implementations from having to do macro expansion and pattern matching.  Such a profile might alleviate a lot of processing burden and be very useful in industry profiles for small devices, for instance.  However, such a profile on its own may not be entirely useful unless it gets incorporated into some specific industry profile, so my desire to do something in between #1 and #2 might just degenerate into doing #2, but I think this is o.k.  As time goes one, industry profiles will emerge in their respective industries or they will come to us with enough of a cross-section to work with us on industry profiles.

Perhaps a good starting point might be to start a catalog of industry profiles that we might need (web services, broadcasting, cellular, airlines, etc.).  We can then just have this list around to refer to.  As these industries begin to require profiles, we can then add pointers on our list to profiles that other people create or that we create with their help.  Also, we could look at the list and see if there are any useful profiles such as "lite" that might be useful for us to develop to make creating industry profiles easier (they could just base their work on "lite" or "medium" or "heavy", for instance).  It might also help test whatever we come up with as best-practices just to look at that list while we have the best-practices in our head and see if anything glares at us.  At least, it might just help put the issue in perspective.

Thanks,
Thomas.

-----Original Message-----
From: Krishna Sankar
To: rights@lists.oasis-open.org
Sent: 9/20/2002 8:53 AM
Subject: RE: [rights] Core, Standard Extension, Conformance and Profiles - A non political discussion

Bob,
 
    Good catch. The reason for that is, because I am *not* assuming Base
Profile = Core Spec. It may very well be; In that case at least the Base
Profile needs to declare concrete elements/types, else we wouldn't be
able to get conformance and interoperability. This would be our work in
the profiles group.
 
    And it is possible that the Base profile would take many of the Core
elements/typesand even some elements from std extensions. Then Core
profile would be the Base profile plus whatever is left out of the core
specs and so on ....
 
cheers

-----Original Message-----
From: DuCharme, Bob (LNG) [mailto:bob.ducharme@lexisnexis.com]
Sent: Friday, September 20, 2002 6:22 AM
To: 'Krishna Sankar'; rights@lists.oasis-open.org
Subject: RE: [rights] Core, Standard Extension, Conformance and Profiles
- A non political discussion

>base is framework, mostly abstract, but the types that build the rights
language
 
which is how I understood core,
 
>core specs = basic profile (in some sense)
 
Yes. But in your first message you wrote
 
>Core Profile (= Base + Core Spec)
 
so now I'm wondering about the distinction between base and core.
Essentially, I had a certain picture of the core vs. standard extension
in my mind (in which the core was mostly abstract types to build on with
extensions) and I'm trying to see how your base relates to those two
components.
 
Bob
 
-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Friday, September 20, 2002 9:15 AM
To: rights@lists.oasis-open.org
Subject: RE: [rights] Core, Standard Extension, Conformance and Profiles
- A non political discussion

Bob,
 
    Good question.
 
    I assume you are talking about core and standard extensions from the
specs point of view ( and !profiles).
 
    My view is that base is framework, mostly abstract, but the types
that build the rights language. Extensions would be optional
sub-elements. The could be complementary as well i.e. different
sub-elements for different domains or functionalities, for example we
could have elements for permanent transfer of control (for sale) and
temporary delegation of control (for renting). My guess is that core
specs = basic profile (in some sense) and the other profiles would
choose from standard extensions or define their own.
 
    Another distinction, Thomas was talking about was that the core
would be static i.e. fewer changes while the standard extensions would
grow over time. So the basic language constructs and vocabularies would
go in the core. From what is there now, I am comfortable with these two
"rules"
 
    Does this make sense or do you see additional rules/guidelines ?
 
    BTW, we could extend the same guidelines for the profiles as well.
the Basic profile would consist of fundamental stuff that one expects in
*every* rights language processor. The only caveat is that we also might
need a Basic-Lite to accommodate resource constraint devices.
 
cheers

-----Original Message-----
From: DuCharme, Bob (LNG) [mailto:bob.ducharme@lexisnexis.com]
Sent: Friday, September 20, 2002 5:50 AM
To: 'Krishna Sankar'; rights@lists.oasis-open.org
Subject: RE: [rights] Core, Standard Extension, Conformance and Profiles
- A non political discussion

Krishna,
 
Could you discuss the distinction between base and standard extensions a
little? As we sort features, I assume we'd want to have some guidelines
to help determine whether something was better off in the former or
latter category, and I was wondering what you had in mind.
 
Bob DuCharme
Consulting Software Engineer, LexisNexis
Data Architecture, Editorial Systems and Content Engineering

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Friday, September 20, 2002 7:54 AM
To: rights@lists.oasis-open.org
Subject: [rights] Core, Standard Extension, Conformance and Profiles - A
non political discussion :o)

Hi all,
 
    Here is my (technical) understanding on the above topic.
 
    a)    The core as it stands now, is a framework. It consists of many
abstract types and relationships between them. Wouldn't make any sense
to make the core mandatory or even a base for conformance.
 
    b)    The standard extensions are a little more concrete, they add a
few more supporting elements.
 
    c)    Which means we need to develop profiles as basis for
implementation and hence conformance.
 
    d)    Different profiles could be disjoint, based on a light-weight
hierarchy. i.e. have a base profile (which everyone should implement)
and then different profiles which could build on each other or stand by
themselves.
 
    e)    For starters, I see three profiles - Base Profile, Core
Profile (= Base + Core Spec) and a standard extensions profile
(=Base+Core Spec+Std Extensions Spec or Core Profile + Std Extensions
Spec)
 
    f)    Now we can discuss conformance. The conformance would be based
on profiles and o the profiles document would say what conformance
means. May be there are levels of conformance for each of the profiles.
Of course, the Base Profile would need to be a binary conformance or in
other words the Base Profile has mandatory full conformance.
 
just some thoughts.
 
cheers
 
BTW, am in Europe doing some EU security work and so missed all the
excitement at the GB meeting.