Re: derivedFrom consistency issue

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