Special-ness of root set: Impl. vs. data model

[Mark Beall]

Which does mean that it should be clearly documented where it does or  
doesn't act like an entity set. This is similar to the part-entity set  
"duality" in iMeshP. A while ago, I went through all of the entity set  
functions and gave my opinion on which of those a part should act like  
an entity set. I think we got close to converging on an agreement on  
that, but probably not totally.

mark

On Aug 31, 2010, at 11:40 AM, Jason Kraftcheck wrote:

> On 08/31/2010 12:20 AM, Mark Miller wrote:
>> On Mon, 2010-08-30 at 19:59, Tim Tautges wrote:
>>> On 08/27/2010 02:37 PM, Miller, Mark C. wrote:
>>>>
>>> I think this is a case where full generality of the data model
>>> conflicts with usability of the interface, where here I
>>> define that as restricting what you can do with/on the root set.
>>
>> I am not sure where '...full generality...' is really coming in here.
>> The data model is the data model. The root set is a) a set and b) the
>> universe set. There is nothing I am doing/suggesting to  
>> 'generalize' the
>> data model. I am merely asking that the root set, since it is a  
>> set, be
>> allowed to be used as a set in ALL instances where a set is  
>> involved and
>> where it make sense at the data model level. I am asking for an
>> interpretation of the root set in the iMesh API that is 'free' from
>> implementation details.
>>
>
> I think I disagree with both of you (Mark and Tim) on one important  
> aspect
> of this:  the root set is not part of the data model.  The data  
> model has:
> the mesh, elements, vertices, entity sets, and tags on any of  
> those.  The
> root set is a fiction in the API to allow a) specifying either the  
> entire
> mesh or an entity set to query functions and b) used to indicate the  
> mesh
> when interacting with tags.  It is not, nor was it ever intended to  
> be, a
> proper set in the sense of the data model.  It is a convenience in  
> the API
> to avoid the need to have separate versions of many functions that  
> act on
> the mesh rather than a subset of the mesh.
>
> - jason