80 likes | 183 Views
Historical Perspective - DICOM Native Models from WG-23. Application Hosting. Model Discussions in WG-23. Occurred in over a dozen meetings and t-cons Began in early 2007, continuing through summer 2008, minor tweaks since then Leveraged earlier work
E N D
Historical Perspective - DICOM Native Models from WG-23 Application Hosting
Model Discussions in WG-23 • Occurred in over a dozen meetings and t-cons • Began in early 2007, continuing through summer 2008, minor tweaks since then • Leveraged earlier work • Suggestions from Guenther Zeilinger(father of dcm4che, a widely used DICOM toolkit for Java) • David Clunie in his enhanced MR validation suite (also used in PixelMed’s DICOM toolkit) • DongbauGuo and Oracle’s schemas for DICOM in XML • Lessons learned from other image formats (e.g. NFTI) • Participants from most major vendors, several smaller vendors, and from academia • Ideas presented and feedback solicited at multiple major conferences.
Why DSDL? • ISO/IEC Standard • Politically correct, as DICOM is an ISO Standard • ISO rules say ‘use ISO Standards when possible’ • The clarity of the Relax NG Compact form • Part of target audience not well versed in XML • Separating out complex validation rules aids clarity • Rich validation capabilities of Schematron • Simple translation to other schema languages • Several tools available to translate Relax NG into XSDL, DTD, and other languages • Can use Schematron rules independent of schema
Alternatives Considered • Use XML Element names derived from DICOM Data Dictionary names • Similar to suggested schema from Emanuel • Problem with unknown DICOM Data Elements • Use XML Element names derived from numeric tag • Not as easy to work with • Strong validators could fail with unknown DICOM Data Elements – schema skew highly likely • Use VR as XML Element, with tag and name as XML Attributes • Easy to support strong type checking • Not natural to most people
Consensus Reached • Simple grammar matching DICOM encoding • Mechanical, bi-directional translation between binary DICOM and the XML Infoset model • Allows searching by either numeric tag or keyword (i.e., DICOM Attribute Name) • Stable Schema – need not change • Dictionary driven • Allows for private DICOM Data Elements • Leverages VR for potential validation • Separately defined enhanced validation using Schematron rules and assertions
Open to Suggestions, but • Any suggested changes must take into account previous decisions: • Must be bi-directional • Must take into account Private Data Elements (important for research use) without breaking • Must allow transparent pass-through (e.g. through Hosting Systems) of unknown DICOM objects • Must not break if Hosting System and Hosted Application are working off different versions of the DICOM Data Dictionary • Must not be onerous for the uninitiated to use
Possible Suggestion • Instead of a generic “Value” XML Element inside the DICOM Data Element, use a VR-specific XML Element (e.g. PNValue, LOValue, SQValue, etc.) • Still a mechanical, bidirectional translation from binary DICOM, given the UN VR • Allows for VR-specific constructs (e.g. names) • May be better for strong type checking (This was considered by WG-23, but was not incorporated. It could be presented again, if that brings a convergence.)
Should WADO use the WG-23 Model? • Having a consistent methodology for representing DICOM in XML is desirable But • Goals may be different The two WGs should converge, but only if their differing goals can be met with a single methodology.