Randall Britten wrote:
18.3 point 9 defines the hidden set for a *component*. 18.4 point 6 refers
to the hidden set of a *variable*.
Similar for encapsulated set and sibling set.
Might be OK as is, but what do you think?
Thanks Randall, this is exactly the type of issue we need to identify
and fix, and I really appreciate your help in finding these types of
issues. I have pushed a fix for this to my public git repo, and also put
it up on my 'latest rendered version of the spec' page.
One thing this raises is how we refer to parts of other people's drafts
- once we have a stable specification, it will be very convenient to say
things like 18.3.9, but the problem with drafts is that the numbers are
changing all the time and adding or removing a section would renumber
everything. We could refer to a particular git commit id together with a
number, e.g.
18.3.9 at commit ac9c214d5ff051229bda8f4668430cc09c3488ef
(http://repo.or.cz/r/cellml-draft-miller.git). However, a simpler
low-tech approach might be to just quote the surrounding text so people
can search for it.
Best regards,
Andrew
-Original Message-
From: [EMAIL PROTECTED] [mailto:cellml-discussion-
[EMAIL PROTECTED] On Behalf Of Alan Garny
Sent: Thursday, 17 January 2008 10:52 p.m.
To: 'CellML Discussion List'
Subject: Re: [cellml-discussion] Base normative CellML Specification
for further work
Dear Andrew,
I quite like the structure of your document. Just one thing though: I
would
like, at this stage, to suggest references to the official CellML
specification. Indeed, you are no doubt very familiar with the official
CellML specification, but in my case it has been years since I have had
a
proper look at it. So, it would help me (and others, I am sure!) if you
could put some references here and there. That would 1) encourage
people to
give you feedback and 2) would save those of us (who are willing to
provide
you with some feedback) a lot of time.
Best wishes, Alan.
-Original Message-
From: [EMAIL PROTECTED] [mailto:cellml-discussion-
[EMAIL PROTECTED] On Behalf Of Andrew Miller
Sent: 16 January 2008 23:30
To: For those interested in contributing to the development of CellML.
Subject: [cellml-discussion] Base normative CellML Specification for
further work
Hi all,
I have recently been working on developing an unofficial 'base'
normative CellML specification to provide something off which
proposed
changes can be based and merged into.
The aim of this unofficial draft specification is to provide a
minimalistic, and normative, specification of all the core
functionality
of CellML. It aims to correct ambiguities and contradictions from
within
the CellML 1.1 specification (and without reactions, simply because
it
wasn't worth adding them to this spec unless the consensus seems to
indicate we might keep them).
The specification as it stands now (which can be obtained from my
public
git repository, using the instructions previously posted, or viewed
at
http://www.cellml.org/Members/miller/draft-normative-
spec/toplevel.xhtml
) needs more careful review of the following aspects:
1) Does the specification lose any important normative information
that CellML 1.1 includes?
2) Is there any part of the specification that can be interpreted
in
more than one way (i.e. ambiguities)? I have been aiming to be very
strict about removing alternative interpretations so there is no
reliance on common sense to guess what the text means - this is the
only
way to ensure that there are no disputes about what the specification
means, and so it would be good to fix even trivially obvious
ambiguities.
Known deviations from 1.1
---
1) Reactions are not described, deliberately.
2) The name attribute on group has not been described. There are
discussion underway about what to do with group - if only
encapsulation
is allowed, we can simplify it and get rid of name, otherwise we may
need to re-add it.
3) The meaning of attributes without explicit namespace prefixes was
defined in 1.1 to override the XML Specification. This had to be
removed
to prevent a conflict between the namespaces in XML normative
reference
and the specification text.
4) There is nothing in the specification corresponding to the
restrictions on group in CellML 1.1 section 6.4.3.2 bullet point 2.
The
reason is that this is somewhat problematic when applied across
imports,
and the assertion in CellML 1.1 that having multiple group elements
makes processing more complex has not been shown to be true in
implementation experience (while testing the rule does make things
more
complex).
5) The restriction that grouping hierarchies must form a tree is only
specified for the encapsulation. This could be extended to all
