LEMS shorthand notation for component definition defies validation

[borismarin]

How are we supposed to capture things like (from https://github.com/LEMS/LEMS/blob/master/examples/example1.xml)

<iaf1 id="celltype_a" threshold="-30 mV" refractoryPeriod="2 ms" capacitance="3uF" />

in the schema???

[borismarin]

maybe http://stackoverflow.com/questions/943659/how-can-i-define-an-xsd-file-that-allows-unknown-wildcard-elements

[borismarin]

or we can always xslt <iaf ...> into <Component type="iaf"> before any validation.

[tarelli]

Not a big fan of <iaf1 it's a shortcut useful only if you think about hand writing LEMS which I personally don't think should be the target.

[borismarin]

I know that @tarelli doesn't like the shorthand notation, but given that 99% of examples use that, a nice automagic conversion wouldn't hurt.

[pgleeson]

I think the bones of an xsl file for the conversion is here: https://github.com/LEMS/pylems/blob/rewrite/xsl/canonical.xsl

[borismarin]

That's useful, @pgleeson. BTW, we need you (and @robertcannon) to make a list of all deprecated constructs in LEMS, so that we can have an "ideal" schema with only supported elements.

[robertcannon]

@tarelli why don't you think hand-writing lems should be the target? In my mind, writing models is like programming, so lems is analogous to a programming language. I wouldn't want to use a programming language without a good IDE, but equally I've never found any value in visual development tools that hide the code (either for programming languages or for XML in fact). Despite (and because of) having invested a fair amount of time in gui-driven model development tools in the past, I suspect that anything that is gui-only is not much use - the goal should be more like a language-aware IDE, in which case the appearance and readability of the code is paramount.

@borismarin for the new lemsml.model and API I'm only including non-deprecated stuff so I hope we can avoid getting it polluted with things we no longer want. I'd expect we can achieve backward compatibility just with xsl transforms to migrate models rather than having to actually implement the deprecated constructs.
Re the schema, yes, the <iaf business makes it un-schema'able. I'd be inclined to support only Component type=... in the schema and regard the <iaf variant as as a shorthand to be converted to canonical form before validation (or use some technology other than xml-schema, but I wouldn't know where to start on that).

[adrianq]

@borismarin and I have been working in the xslt transformation.

@pgleeson this is the new xsl generated from the bones you suggested: https://github.com/tarelli/org.lemsml.model/blob/boris/src/main/resources/Schemas/canonical.xslt

There are two things missing in the xslt:

• Add all the lems clauses here https://github.com/tarelli/org.lemsml.model/blob/boris/src/main/resources/Schemas/canonical.xslt#L23
• Check if it is still working fine when no nms is provided.

We have generated some tests and utils classes here: https://github.com/tarelli/org.lemsml.model/tree/boris/src/test/java/org/lemsml/model/test
They allow to validate again the schema, unmarshall a LEMS docs and XSLT transform the document.

[robertcannon]

Hi,
for the first point you should be able to write it so you only need the elements that can occur at the top level in LEMS - Target,Dimension,Unit,Assertion,Insertion,Constant and ComponentType. All the others only occur inside ComponetTypes so if you just copy the whole element as-is without recursively applying templates then the transform shouldn't need to know anything about the contents.

• but if you do that, you should probably keep Component itself out of the list. You might get a case with a nested <iaf -style element inside a <Component style one in which case, you do want to match inside the element.