'encoding' attribute must be allowed on more elements

[sbmlsecretary]

needs to be allowed on semantics, annotation and annotation-xml

Reported by: sarahkeating

Original Ticket: "sbml/sbml-specifications//100":https://sourceforge.net/p/sbml/sbml-specifications//100

[sbmlsecretary]

Logged In: YES user_id=862059 Originator: NO

According to our own MathML subset schema it is an required attribute for annotation and annotation-xml. However, the semantics element may not have an encoding as its only attributes are those of MathBase.

Therefore it should be allowed on annotation and annotation-xml but not on semantics.

Original comment by: shoops

[sbmlsecretary]

Logged In: YES user_id=862059 Originator: NO

I am accepting this issue as valid.

Original comment by: shoops

[sbmlsecretary]

Logged In: YES user_id=641982 Originator: YES

Actually I agree with Stefan that the semantics element shouldnt have an encoding - I just threw it in because of the way MathML uses it. I'm more than happy for the encoding to be on the annotation element!

Original comment by: sarahkeating

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

I'm slightly confused about the items posted by Stefan and Sarah, so let me start from scratch.

Full MathML 2.0 permits the 'encoding' attribute on <semantics>. See sections 4.4.11.2.1 and 4.3.2.4 of the MathML 2.0 specification. In SBML, the MathML subset has a lot of things removed compared to the full 2.0 definition of MathML. The 'encoding' attribute on <semantics> is one such. The original reason (worked out by Andrew back in L2v1 days) is that for purposes to which SBML puts MathML markup, it adds complexity for an application to support 'encoding' on <semantics> yet there is no obvious gain. So, the MathML subset for SBML just omits this as an available attribute.

If there is no reason why we think we really need to support 'encoding', then I propose we close this issue and not expand validation rule 10203. It's a bit arbitrary, yes, and I can see the temptation to add it, but there's going to be enough trouble with 'encoding' on <semantic>'s <annotation> tag.

Original comment by: mhucka

[sbmlsecretary]

• status: open --> pending

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=641982 Originator: YES

I agree that we shouldnt allow 'encoding' on <semantics>

BUT

it is actually required (according to our MathML subset) on <annotation> and <annotation-xml> so the rule shouldnt say that encoding is only allowed on csymbol

Original comment by: sarahkeating

[sbmlsecretary]

• status: pending --> open

Original comment by: sarahkeating

[sbmlsecretary]

Logged In: YES user_id=862059 Originator: NO

Rule 10203 prohibits the encoding attribute on all elements but the csymbol. This is incorrect as the SBML MathML subset allows it on the elements annotation and annotation-xml.

We have two options A) Disallow the encoding attribute on the elements annotation and annotation-xml. B) Change the rule to:

10203. In the SBML subset of MathML 2.0, the MathML attribute encoding is only permitted on csymbol, annotation and annotation-xml. No other MathML elements may have the encoding attribute.

Since annotation makes no sense without the encoding attribute my vote is B)

Original comment by: shoops

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

I don't disagree with extending rule 10203 to <annotation> and <annotation-xml> (but I see I never actually made that clear -- sorry for the confusion). I agree it should be done and therefore that the rule needs to be changed. I was really only trying to address putting 'encoding' on <semantics>, which I think we shouldn't do.

So the bottom line is: yes, 10203 needs to be broadened to allow 'encoding' on <annotation> and <annotation-xml>.

Original comment by: mhucka

[sbmlsecretary]

• status: open --> pending

Original comment by: lenov

[sbmlsecretary]

Logged In: YES user_id=1045203 Originator: NO

I am fine with encoding on annotation and annotation-xml yes while on semantics no.

Original comment by: lenov

[sbmlsecretary]

Logged In: YES user_id=1045203 Originator: NO

I agree with the proposed change and that it should be done.

Original comment by: lenov

[sbmlsecretary]

• milestone: 678078 --> Accepted:_Changes_with_conformance_implications
• status: pending --> closed

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

Fixed for SBML L2v3r2.

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

Fixed for SBML L2v3r2.

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

Fixed for SBML L2v3r2.

Original comment by: mhucka

[sbmlsecretary]

• summary: Rule 10203 encoding --> Rule 10203 is overly restrictive about 'encoding' attribute

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

In addition to changing the validation rule, the text on p.21 line 30 also needs to be amended.

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: NO

I changed the title of this item in order to reflect the fact that this is not only about validation rule 10203.

Original comment by: mhucka

[sbmlsecretary]

• summary: Rule 10203 is overly restrictive about 'encoding' attribute --> 'encoding' rule must be allowed on more elements

Original comment by: mhucka

[sbmlsecretary]

• summary: 'encoding' rule must be allowed on more elements --> 'encoding' attribute must be allowed on more elements

Original comment by: mhucka