Subject: Re: Audit of packages

From: Peter Blatherwick <[email-masked]>
Date: Tue, 10 Oct 2000 13:12:18 -0400

I agree in general, since "extends" basically means "clone the base package
and add some more functionality" (no subsetting, over-riding etc allowed).
In example below pkg2 by definition implements pkg3.  (Not the case with
re-versioning of Packages though!)

One clarification however.  It does not always make sense for a base package
to be published as implemented by an MG.  There are examples where the base
package is defined such that it acts similar to a virtual class, and has no
function on its own, simply defining interface for one or more derived
packages.  Annex E ToneGen and ToneDet as well as a few packages in Annex G
are examples.  Therefore, implementer's guide MUST not make a hard and fast
rule on this, but SHOULD say "SHOULD" with some words to describe where its
inappropriate.

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 09, 2000 16:03
To: [email-masked]
Subject: Re: Audit of packages

We've been around this and basically, it is up to the MG.
It does not HAVE to report pkg3, but it could.  Maybe SHOULD
is a good word, and I wonder if text to that effect
should go in the implementor's guide?

Brian

-----Original Message-----
From: Sachin Mittal [mailto:[email-masked]]
Sent: Monday, October 09, 2000 5:12 AM
To: [email-masked]
Subject: Audit of packages

Say a termination abc implements the following packages:
1. pkg1
2. pkg2
where pkg2 extends pkg3 and pkg1 doesn't extend any other package

If this termination is audited for packages implemented on it,
should the reply include pkg3 with pkg1 and pkg2 (base package names
are included)

Sachin

---

From: Christian Groves <[email-masked]>
Date: Thu, 12 Oct 2000 13:24:38 +1100

Perhaps we "should" say "SHALL", I can't think of a case of when it is
inappropriate and we have the rule saying that you can address
properties by pkg3.

But, I'm happy with Should if you can provide the text when it is
inappropriate.

Cheers, Christian

Peter Blatherwick wrote:
>
> I agree in general, since "extends" basically means "clone the base
> package and add some more functionality" (no subsetting, over-riding
> etc allowed).  In example below pkg2 by definition implements pkg3.
> (Not the case with re-versioning of Packages though!)
>
> One clarification however.  It does not always make sense for a base
> package to be published as implemented by an MG.  There are examples
> where the base package is defined such that it acts similar to a
> virtual class, and has no function on its own, simply defining
> interface for one or more derived packages.  Annex E ToneGen and
> ToneDet as well as a few packages in Annex G are examples.  Therefore,
> implementer's guide MUST not make a hard and fast rule on this, but
> SHOULD say "SHOULD" with some words to describe where its
> inappropriate.
>
> -- Peter
>