View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003177 | Slicer4 | Core: CLI infrastructure | public | 2013-06-18 13:16 | 2013-06-20 11:16 |
Reporter | hans_meine | Assigned To | millerjv | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | open | ||
Product Version | Slicer 4.2.1 | ||||
Target Version | Fixed in Version | ||||
Summary | 0003177: CLI modules' XML output does not comply to specs | ||||
Description | I have written a parser in Python for the --xml output of the CLI modules that come with Slicer. Below, you find a number of warnings, grouped by module, that indicate where there's a mismatch between their output and CTK/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd, after which I modeled my parser. Actually, this already assumes that https://github.com/jcfr/CTK/tree/279-tweak-cmdlinemodule-library-for-slicer-integration gets merged, in which 'transform', 'table', and 'measurement' elements are allowed again. I think we should not assume that all needs to get fixed in the XML, e.g. I wonder if a 'step' within 'constraints' could be made optional in the .xsd instead. Also, let me point out that OtsuThresholdImageFilter is the only module with an xmlns attribute: | ||||
Additional Information | === ACPCTransform === === AffineRegistration === === BRAINSDemonWarp === === BRAINSFit === === BRAINSFitEZ === === BRAINSResample === === BRAINSROIAuto === === BRAINSTransformConvert === === BSplineDeformableRegistration === === BSplineToDeformationField === === CastScalarVolume === === CreateDICOMSeries === === CurvatureAnisotropicDiffusion === === DiffusionWeightedVolumeMasking === === DTIimport === === DWIConvert === === ExecutionModelTour === === ExpertAutomatedRegistration === === GaussianBlurImageFilter === === GradientAnisotropicDiffusion === === GrayscaleModelMaker === === LinearRegistration === === MedianImageFilter === === ModelMaker === === MultiResolutionAffineRegistration === === N4ITKBiasFieldCorrection === === PETStandardUptakeValueComputation === === ResampleDTIVolume === === ResampleScalarVectorDWIVolume === === RigidRegistration === === SimpleRegionGrowingSegmentation === === ThresholdScalarVolume === === VBRAINSDemonWarp === | ||||
Tags | Summer AHM 2013 | ||||
There is no "official" xsd for the ModuleDescriptionParser. Several attempts have been made to retrofit an xsd but they have all been incomplete. To me, it is not that the CLI modules do not conform to the xsd but that the xsd does not conform to the parser in ModuleDescriptionParser. |
|
Thanks, Jim. Nevertheless, many of the above warnings indicate improper XML descriptions. E.g. I think every parameter should have a name (identifier), no? (OK, I could probably fall back to the longflag.) Otherwise, I agree – as I said, this is not a "the XML is wrong" report, but a "there's a mismatch" report. At the same time, I would not agree that this can be interpreted as "[just] the xsd is wrong". Both seem to need fixing. |
|
Also, the "ModelMaker" module has an "aggregate" attribute for the geometry parameter, which is not in the .xsd (not even in the above branched one). |
|
We should also document and check the format of field values, e.g. the file extensions being a comma-separated list of exensions starting with a dot, or the contributors being a comma-separated list, not e.g. freeform-text like "This tool was developed by Hans J. Johnson and Greg Harris." (seen with VBRAINSDemonWarp). At least the latter is a requirement for MeVisLab, which currently complains about illegal characters in the author tag. Furthermore, the description sometimes contains HTML, sometimes plain text with double newlines separating paragraphs. |
|
I also found that the flag/longflag sometimes start with '-' / '--', respectively, but sometimes just contain the flag name without prefix. It should be documented what is expected. I vote for the inclusion of dashes (or similar) in the XML, because that could eventually be used to use other syntax, like single-dash -longflags, or Windows-style /f flags. (It could even be used for programs that don't prefix their options at all.) |
|
I am not sure if I should file a separate issue about this, but another problem with the spec is this:
That is not correct for output parameters. At least the ExecutionModelTour specifies parameters with channel="output" which do not need index or flags; they are put into an ascii output file with key=value pairs. The key in these files is just the parameter name; no flag involved. Another issue is that this obviously needs to be documented, because so far only Jim seemed to know about that. :-) |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2013-06-18 13:16 | hans_meine | New Issue | |
2013-06-18 13:16 | hans_meine | Status | new => assigned |
2013-06-18 13:16 | hans_meine | Assigned To | => millerjv |
2013-06-18 13:53 | millerjv | Note Added: 0008780 | |
2013-06-18 14:06 | hans_meine | Note Added: 0008781 | |
2013-06-18 14:12 | hans_meine | Note Added: 0008782 | |
2013-06-18 15:50 | hans_meine | Note Added: 0008783 | |
2013-06-19 19:06 | hans_meine | Note Added: 0008792 | |
2013-06-19 21:54 | jcfr | Tag Attached: Summer AHM 2013 | |
2013-06-20 11:16 | hans_meine | Note Added: 0008797 |