Re: derivedFrom consistency issue

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