CellML Discussion List

Text archives Help


[cellml-discussion] problem in spec on grouping


Chronological Thread 
  • From: whedley at sdsc.edu (Warren Hedley)
  • Subject: [cellml-discussion] problem in spec on grouping
  • Date: Thu Aug 5 15:32:42 2004

Hi Matt,

Your analysis is correct. The word unnamed is redundant in section 6.4.2.4.

The confusion in 6.2.2 p2 comes from the fact that we initially
considered disconnected hierarchies to be distinct. For instance, figure
8 could be said to contain 2 hierarchies. However the "anonymous"
component combines them into a single hierarchy.

This should probably be re-written:

A model may contain any number of disconnected hierarchical groupings of
components, ...

or something like that. Feel free to add it to the errata.

Good spotting. I'm amazed anyone read the spec closely enough to notice.

Regards,
Warren


Matt Halstead wrote:
> from http://www.cellml.org/public/specification/grouping.html we have :
>
>
> section 6.2.2 paragraph 2
>
> A model may contain any number of encapsulation hierarchies, as long as
> these do not overlap. If more than one hierarchy is explicitly defined,
> it may be useful to combine these into a single hierarchy by assigning
> all unencapsulated components an anonymous parent component. This
> anonymous component could make it easier to check that the hierarchies
> do not overlap and do not define any circular relationships between
> components.
>
> section 6.4.2 The <relationship_ref> element
>
> 4. Proper use of the name attribute
>
> A name attribute must not be defined on a <relationship_ref>
> element with a relationship attribute value of "encapsulation". [ A
> model must define at most one unnamed encapsulation hierarchy. ]
>
>
> This latter part - [ A model must define at most one unnamed
> encapsulation hierarchy. ] - seems wrong. Encapsulation hierarchies
> cannot be named anyway, so mentioning 'unnamed' is redundant, but
> according to 6.2.2 we can define as many non-overlapping hierarchies as
> we want.
>
> Perhaps it was meant to read - unnamed containment hierarchies - but
> section 6.2.4 would suggest you can have as many as you want of either a
> particular named group or unnamed group.
>

--
Warren Hedley
Alliance For Cell Signaling
San Diego Supercomputer Center
>From matt.halstead at auckland.ac.nz Thu Aug 5 15:41:24 2004
From: matt.halstead at auckland.ac.nz (Matt Halstead)
Date: Thu Aug 5 15:41:58 2004
Subject: [cellml-discussion] problem in spec on grouping
In-Reply-To:
<4111A95D.1090300 AT sdsc.edu>
References:
<5B6645EA-E683-11D8-8E50-000A95B32AC4 AT auckland.ac.nz>

<4111A95D.1090300 AT sdsc.edu>
Message-ID:
<52FA4C0C-E691-11D8-8E50-000A95B32AC4 AT auckland.ac.nz>

Thanks Warren, that clears it up nicely.

cheers
Matt


On 5/08/2004, at 3:28 PM, Warren Hedley wrote:

> Hi Matt,
>
> Your analysis is correct. The word unnamed is redundant in section
> 6.4.2.4.
>
> The confusion in 6.2.2 p2 comes from the fact that we initially
> considered disconnected hierarchies to be distinct. For instance,
> figure 8 could be said to contain 2 hierarchies. However the
> "anonymous" component combines them into a single hierarchy.
>
> This should probably be re-written:
>
> A model may contain any number of disconnected hierarchical groupings
> of components, ...
>
> or something like that. Feel free to add it to the errata.
>
> Good spotting. I'm amazed anyone read the spec closely enough to
> notice.
>
> Regards,
> Warren
>
>
> Matt Halstead wrote:
>> from http://www.cellml.org/public/specification/grouping.html we
>> have :
>> section 6.2.2 paragraph 2
>> A model may contain any number of encapsulation hierarchies, as long
>> as these do not overlap. If more than one hierarchy is explicitly
>> defined, it may be useful to combine these into a single hierarchy by
>> assigning all unencapsulated components an anonymous parent
>> component. This anonymous component could make it easier to check
>> that the hierarchies do not overlap and do not define any circular
>> relationships between components.
>> section 6.4.2 The <relationship_ref> element
>> 4. Proper use of the name attribute
>> A name attribute must not be defined on a <relationship_ref>
>> element with a relationship attribute value of "encapsulation". [ A
>> model must define at most one unnamed encapsulation hierarchy. ]
>> This latter part - [ A model must define at most one unnamed
>> encapsulation hierarchy. ] - seems wrong. Encapsulation
>> hierarchies cannot be named anyway, so mentioning 'unnamed' is
>> redundant, but according to 6.2.2 we can define as many
>> non-overlapping hierarchies as we want.
>> Perhaps it was meant to read - unnamed containment hierarchies - but
>> section 6.2.4 would suggest you can have as many as you want of
>> either a particular named group or unnamed group.
>
> --
> Warren Hedley
> Alliance For Cell Signaling
> San Diego Supercomputer Center
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion AT cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion




Archive powered by MHonArc 2.6.18.

Top of page