Re: [sbml-groups] group specs

[Chris J. M. <my...@ec...>]

> 
> This is why I didn't call it a 'ListOf' in the first place, but Sarah
> insisted ;-)  This feels like a remarkable amount of overkill and
> indirection to me, when the whole point was just to have a single
> extra attribute on a container, but enh.  Would you all be happier if
> I dropped the 'id' and 'name', and just left the 'membersShareType'
> instead?
> 
That would be fine especially given that as Sarah pointed out that FBC already has a list with an attribute.  

Did we actually agree to add Id and Name to lists for L3V2?  I thought it was everything but lists, but I may be mistaken.

>>> 
> I was actually imagining using whatever the text was that in the
> actual file, i.e. "groups:idRef" or "spatial:variable" or what have
> you.  I think most XML parsers would accommodate that, and it's
> certainly the simplest solution.  But if we wanted to go for a more
> formal approach, we could do that.  The options are:
> 
> 1) Use pre-defined labels for each package, "groups:id" would mean the
> same thing even if a particular document called the groups namespace
> 'sbmlGroups'.
> 2) Use document-defined labels for each package.  If a document called
> the groups namespace 'sbmlGroups', you'd use 'sbmlGroups:id'.
> 3) Have two attributes, one with the namespace URI and one with the
> attribute name:  distinctAttribute="id"
> distinctAttributeURI="http://sbml.org/sbml/level3/version1/groups/version1"
> 
> I was thinking of going with 2, but could be argued otherwise.  In any
> event, the text can be clarified.

Subtle point.  I hand not realized that we are happy with SBML documents that use different short namespace names.  I have been assuming that these were fixed.  I'm not sure if this is a problem though as I think I've only ensured that files I create always use the same short label.  However, it might be good to have some testcases which have different short labels to be sure this gets checked.
> 
>>> Instead of having an element like MemberConstraint that has some
>>> mutually exclusive attributes, why not creating two distinct classes
>>> DistinctAttributeConstraint and IdenticalAttributeConstraint that extend
>>> MemberConstraint.
>>> 
>> 
>> I like this idea.
> 
> We can do this, but it seems like an arbitrary change.  It would mean
> that the ListOf would contain different sub-classes of things, but we
> do already have that with listOfRules, so hey.
> 
I think Nico's approach here is cleaner perhaps.  I don't have a strong feeling either way though.

Cheers,

Chris