Validation rules for SBase subclasses in packages

[Zhang, Fengkai (NIH/NIAID) [E]]

Dear all,

While working on the validation rules for the multi package, I have a question about the validation rules for the new classes in an SBML package inheriting the SBase class. I noticed that in many packages, there are rules for the new classes of the SBase subclass in the format of "A {NewPackageClass} object may have the optional SBML Level 3 Core attributes metaid and sboTerm. No other attributes from the SBML Level 3 Core namespace are permitted on a {NewPackageClass}". I would consider this rule should have been implemented for the SBase class in SBML L3V1 core, and if so, it might not be necessary to be enforced again in a sub-class. Is there any reason to have those rules for the new SBase classes in packages?

Regards,

Fengkai

===============================
Fengkai Zhang, MD, MMath
Staff Scientist
Laboratory of Systems Biology, DIR, NIAID
9000 Rockville Pike
Building 4, Room 137
MSC 0421
Bethesda MD 20892
Phone: 301.496.0985
Fax: 301.480.1660
NIAID, National Institutes of Health, DHHS



"Disclaimer:

The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. "

[Lucian Smith]

That's a great question, and one I remember being curious about when I was writing the comp package, too.

The answer is that while the specs are written such that inheritance is clear, the validation rules are written to be inheritance-unaware.  If you look in the core spec, you'll see the same thing--every class that inherits from SBase repeats the same validation rules that it inherits from SBase (such as the one you quote above), for each new class in question.  I wasn't there when that pattern was established, but I assume it was done to make validation rules more easily able to stand alone, so that when validating a document, it's clear to the user what specific object had a problem.  

It's also true that many elements add to the core namespace attributes that an element may have, so their own rules change to things like, "A Model object may only have the following attributes, all of which are optional: metaid, sboTerm, id, name, substanceUnits, timeUnits, volumeUnits, areaUnits, lengthUnits, extentUnits and conversionFactor."  While this can't happen for package elements that inherit from SBase (since packages only add attributes in their own namespace), a package might extend these sub-classes themselves, to get a new object that inherited from Parameter instead of SBase, for example.  In those cases, the rule that applied to SBase would not quite apply to the new class, as Parameter added new attributes from the core namespace that could be used.

You do end up with a lot of cutting and pasting, but in the end, I think it's probably best to go ahead and be explicit, and write validation rules that are essentially inheritance-unaware.

-Lucian

--
You received this message because you are subscribed to the Google Groups "sbml-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbml-discuss...@googlegroups.com.
To post to this group, send email to sbml-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbml-discuss/C146BB646A4E544997CAC4966594B546227DD548%40MLBXV01.nih.gov.
For more options, visit https://groups.google.com/d/optout.

[Sarah Keating]

> The answer is that while the specs are written such that inheritance is
> clear, the validation rules are written to be inheritance-unaware.

It is also to do with reporting line numbers and the actual element that
is at fault. It makes reporting the user exactly where a problem was
much easier.

In addition the numbering of the validation rules can be used to
identify what type of element causes the problem - rather than having
generic SBase numbers that apply to anything.

I know that this an implementation issue would could be engineered in
software but it is better if the list of rules reflects rules that might
be returned on validation.

Sarah

[Zhang, Fengkai (NIH/NIAID) [E]]

Thank Sarah and Lucian for pointing out the background and advantages of the current approach. Is it recommended for the inheritance of all class types or only for subclasses of SBase? For example in the multi package, I am considering to use a new subclass of SpeciesType, say BindingSiteSpeciesType, to serve for those SpeciesType objects with "true" values of their isBindingSite attributes under the current draft spec, and drop the isBindingSite attribute from the SpeciesType class. If applying the similar method of the validation rules for the subclasses of SBase, most or all of the validation rules for SpeciesType need to be duplicated for the new BindingSiteSpeciesType class. From implementation perspective, if inheritance could be enabled for validation rules, one possible way to distinguish parent and derived classes could be adding the name of invoking class to the messages. Nevertheless, it is ok to use the current approach for the multi package to be consistent to SBML core and other packages.

Fengkai

===============================
Fengkai Zhang, MD, MMath
Staff Scientist
Laboratory of Systems Biology, DIR, NIAID
9000 Rockville Pike
Building 4, Room 137
MSC 0421
Bethesda MD 20892
Phone: 301.496.0985
Fax: 301.480.1660
NIAID, National Institutes of Health, DHHS



"Disclaimer:

The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. "

________________________________________
From: Sarah Keating [skea...@caltech.edu]
Sent: Wednesday, October 22, 2014 3:49 AM
To: sbml-d...@googlegroups.com
Cc: Discussions of the SBML Level 3 'multi' package
Subject: Re: [sbml-discuss] Validation rules for SBase subclasses in packages

--
You received this message because you are subscribed to the Google Groups "sbml-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbml-discuss...@googlegroups.com.
To post to this group, send email to sbml-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbml-discuss/54476190.3050106%40caltech.edu.

[Sarah Keating]

Hi Fengkai

On 22/10/2014 16:38, Zhang, Fengkai (NIH/NIAID) [E] wrote:
> Is it recommended for the inheritance of all
> class types or only for subclasses of SBase? For example in the multi
> package, I am considering to use a new subclass of SpeciesType, say
> BindingSiteSpeciesType, to serve for those SpeciesType objects with
> "true" values of their isBindingSite attributes under the current
> draft spec, and drop the isBindingSite attribute from the SpeciesType
> class. If applying the similar method of the validation rules for the
> subclasses of SBase, most or all of the validation rules for
> SpeciesType need to be duplicated for the new BindingSiteSpeciesType
> class.

Actually I don't think you would have to repeat all the rules for the
derived class. 'comp' also has the situation where there are classes
derived from others and the comp spec does not reiterate every rule for
each class.

I think a good 'rule of thumb' is that if a class is derived solely from
an abstract class then the rules relating to the abstract class do need
to be repeated for the derived class. However if your class is further
derived from a non-abstract class you do not need to relist rules. IIRC
this is a consequence of when we stopped having the general rule "The
file must conform to an xsd schema" and started to list ALL the rules
separately.

Sarah

[Zhang, Fengkai (NIH/NIAID) [E]]

Thanks, Sarah. I will use the way comp uses.

Fengkai

===============================
Fengkai Zhang, MD, MMath
Staff Scientist
Laboratory of Systems Biology, DIR, NIAID
9000 Rockville Pike
Building 4, Room 137
MSC 0421
Bethesda MD 20892
Phone: 301.496.0985
Fax: 301.480.1660
NIAID, National Institutes of Health, DHHS



"Disclaimer:

The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. "

________________________________________
From: Sarah Keating [skea...@caltech.edu]

Sent: Monday, October 27, 2014 4:36 AM
To: Discussions of the SBML Level 3 'multi' package; sbml-d...@googlegroups.com
Subject: Re: [sbml-multi] [sbml-discuss] Validation rules for SBase subclasses in packages

--
You received this message because you are subscribed to the Google Groups "sbml-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbml-discuss...@googlegroups.com.
To post to this group, send email to sbml-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbml-discuss/544E040F.50304%40caltech.edu.