UnitKind must go and its values put in UnitSID space instead

[sbmlsecretary]

SBML L2v2r1 p.31 & 33

Stefan Hoops pointed out that with UnitKind being a separate enumeration, and its values not actually being in the space of values in UnitSId, we have an error: you cannot actually technically use any of the UnitKind values in a species/compartment/parameter units specification! For example, you can't actually put units="mole" or units="dimensionless" on a parameter definition as the spec is currently written.

I see two alternative approaches to solving this:

1) (Preferred but requires yet another un-voted schema change): remove UnitKind, and simply make the list of values from UnitKind be predefined reserved values in UnitSId.

2) Keep everything as is, and say that all the values from UnitKind are "inserted" somehow in the value space of UnitSId.

Reported by: mhucka

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

[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=862059 Originator: NO

We deliberately choose to not use xsd:ID and xsd:IDREF types at all. Instead we explain all id restrictions or reference situation in words and validation rules. Since we do not want to change this at this moment in time I propose that solution 2 is the way to go. All UnitKind enumeration values are valid UnitSId values, therefore we do not really break any current standards when we just say that whenever a UnitSId is used for reference it might be a UnitSId of a unitDefintion or a UnitKind enumeration value. This is similar to the reverse situation where we restrict the values of UnitSId when it is used as an identifier.

Original comment by: shoops

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: YES

Stefan,

I'm not sure what you mean about the ID/IDREF issue -- UnitSId is not derived from ID.

Original comment by: mhucka

[sbmlsecretary]

Logged In: YES user_id=641982 Originator: NO

I am accepting this issue as valid.

Original comment by: sarahkeating

[sbmlsecretary]

Logged In: YES user_id=641982 Originator: NO

I would go with 1.

Reasons: a) Its tidier and most logical b) So few models use units yet anyway and when we had the whole offset debate it was generally agreed that if we are going to encourage people to use units we need to have got them totally correct AND easy to use. c) I think we will have to go for 1 eventually so why not now - the community is aware that there will be schema changes for l2v3 and since they are all waiting for us to finalise it ...

Note: the builtin units should also be included as restricted values of UnitSId

Original comment by: sarahkeating

[sbmlsecretary]

Logged In: YES user_id=862059 Originator: NO

Mike,

With the ID/IDREF issue I am referring to the decision not to derive SId from ID. We did that as this would only give us one name space in L1. This was crucial at that point in time as we did not have the name attribute. When going to level 2 we kept the SId definition to be more compatible with L1.

Using ID/IDREF would have allowed us to put a lot of restrictions in the DTD or schema. We are not using this mechanism at all because of the above stated shortcomings. Instead, we are explaining everything in words in the document.

Since everything related to ID definition and reference situations is explained in words and not rooted in the schema, using a UnitKind value in a place where a UnitSId is used as a reference is not a schema violation.

Please note that UnitSId is currently defined as derived form SId by restriction without any restrictions being mentioned. The restriction applied to UnitSId when it is used as the id attribute of unitDefintion is only explained in words and not expressed in the schema.

Since it seems a other people prefer a schema change I would like to see the the proposes changes expressed these changes in XML.

Thanks, Stefan

Original comment by: shoops

[sbmlsecretary]

Logged In: YES user_id=1045203 Originator: NO

Re: SID/ID. There is another reason to not use ID is L2: most people wanted to be able to overide global parameters.

I am more in favor of 2 for L2V3. However, I can see why Sarah disagrees, and I would be fine with it as well.

Original comment by: lenov

[sbmlsecretary]

Logged In: YES user_id=1045203 Originator: NO

I am accepting this issue as valid.

Original comment by: lenov

[sbmlsecretary]

• status: open --> pending

Original comment by: lenov

[sbmlsecretary]

Logged In: YES user_id=343670 Originator: YES

Fixed for L2v3r1.

Original comment by: mhucka

[sbmlsecretary]

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

Original comment by: mhucka