Re: derivedFrom consistency issue

The issue we are discussing is originated from that the elements inside the <derivedFrom> are parallel with outer elements. If we assign every derivedFrom with an ID, that is to move the elements inside the derived one level below the outer elements, e.g.,
<derivedFrom elementID="1">typeA</derivedFrom>
<element elementID="2">...</element>
....
In such way, we only need to be sure that the assigned derivedFrom elementID is unique rather than all elementIDs inside derivedFrom are unique. 

thanks,
weiming
----- Original Message ----- 
From: "Joel M. Halpern" <[email protected]>
To: <[email protected]>
Sent: Tuesday, October 17, 2006 9:53 PM
Subject: Re: derivedFrom consistency issue


> I would hope that we will not get into a situation where different 
> FEs supporting the same version of the same LFB Class will use 
> different identifiers for the same element of the LFB Class?
> 
> Can you please elucidate on what the meaning of the ID on the 
> derivedFrom would be for?  A derivedFrom class or structure currently 
> inherits its parents full definition.  That is the purpose of derivedFrom.
> 
> Yours,
> Joel M. Halpern
> 
> At 07:58 AM 10/17/2006, Wang,Weiming wrote:
> >Yes, it's easy for a person to know his parant's name, but how many 
> >persons know their grand and grand parant's name?
> >
> >When one derives from a relative huge LFB, like a IPv6 forwarder, 
> >due to this problem, there may be a possibility one have to chase a 
> >lot and make notes on every ID used.
> >
> >To let a derivedFrom have an ID, like <derived From elementID="x"> 
> >may make the clause have a good sealed property.
> >
> >thanks,
> >weiming
> >
> >----- Original Message -----
> >From: "Joel M. Halpern" <[email protected]>
> >
> > > It is true that derived from elementIDs have to avoid the identifiers
> > > of the parent classes.  However, that is generally easy to do.
> > > If you are deriving from a parent, you are looking at the parent
> > > definition.  Just start with IDs where it leaves off.
> > >
> > > Remember that two different children (B and C) of the same parent (A)
> > > do not need to worry about collision with each other.  The CE knows
> > > whether it is looking at a B or a C, and does not get confused if
> > > they both use element ID 7.  But they can not use any element IDs 
> > used in A.
> > >
> > > Yes, it would be nice if it were automatic.
> > > But that does not seem like enough reason to give up
> > > derivedFrom.  Note that the model already uses derivedFrom internally.
> > >
> > > Yours,
> > > Joel M. Halpern
> > >
> > > At 02:35 AM 10/17/2006, Wang,Weiming wrote:
> > > >It seems that the <derivedFrom> clause should require xml writers to
> > > >keep uniqueness of used elementIDs by themselves, i.e., the current
> > > >defined elementIDs should be assured not used in all the parents and
> > > >parents' parents...
> > > >
> > > >If this is true. The <derivedFrom> merits drop greatly. It may also
> > > >become a place persons are easy to produce bugs.
> > > >
> > > >thanks,
> > > >Weiming