keywords for command elements?

[gunter zeilinger]

CP-850 [ ftp://medical.nema.org/medical/dicom/final/cp850_ft.pdf ]
defines keywords as additional identifiers for DICOM Data Elements,
deriving them from the attribute name using Camel case notation.

When trying to align dcm4che2 (a DICOM implementation in Java) Tag
constant names to CP-840, I stumbled over name clashes, between the
Data Elements:

(0008,0001) VR=UL, VM=1 Length to End RET
(0008,0010) VR=CS, VM=1 Recognition Code RET
(0008,0040) VR=US, VM=1 Data Set Type RET
(2010,0060) VR=CS, VM=1 Magnification Type

and the Command Elements:
(0000,0001) VR=UL, VM=1 Length to End RET
(0000,0010) VR=CS, VM=1 Recognition Code RET
(0000,0800) VR=US, VM=1 Data Set Type
(0000,5180) VR=CS, VM=1 Magnification Type RET

because (current version of) dcm4che2 use a common dictionary for Data
and Command elements.

Before, splitting the dictionary in dcm4che2, or applying a different
name->keyword transformation for Command elements, I would like to ask
if there is any intention by DICOM, or interests by other DICOM users,
to define also keywords for command elements in the standard text,
also taking care to avoid clashes with keywords for DICOM Data
elements defined in CP-850.

If so, I will volunteer to provide a draft of a corresponding CP :)
--
gunter

[Victor Derks]

Hi Gunter,

We use currently 4 groups of constant classes: CommandTag, DataTag,
FileMetaTag, DirectoryTag in our library (actually working around this
problem). We are thinking however about merging all constant values
into 1 class somewhere in the future as people find it sometimes hard
to find the correct class.

To reduce the amount of constant values, our code generation process
also suppresses by default all retired tags, unless explicit enabled.
This could also be a solution for dcm4che2. By concept most retired
tags don't need a const value as they are not used in code anymore
(exceptions allowed of course).

On the other hand non-clashing names could prevent iterating small
issues in the future (for example the name field in our XDS schema
isn't of type id, because of this problem).

Victor

[David Clunie]

Hi Gunter

I always forget to check these, since they are in Part 7 rather than
Part 6,
but yes, a CP would be appropriate, perhaps prefixing the word
"Command"
before each of the problem group 0x0000 elements in question (but
leaving the conflicting ones alone). The CP should probably also add
the old (retired) ACR-NEMA group 0x0000 elements in as well, so
that we never inadvertently re-use them for something else. If you
write it and get it to Rob today, he can get it into the system at
this
week's WG 6 meeting.

David

[gunterze]

Hi David,

Shall the CP also take care that all keywords are valid Java/C
identifiers by (for instance) defining "_3DRenderingType" instead
"3DRenderingType" as keyword for data element: 3D Rendering Type
(0072,0520) ?

gunter

[David Clunie]

Sure; I thought I had already submitted a CP on that, but might
not have submitted it yet, so go ahead and include it.

David

[Marco Eichelberg]

Gunter,

> Shall the CP also take care that all keywords are valid Java/C
> identifiers by (for instance) defining "_3DRenderingType" instead
> "3DRenderingType" as keyword for data element: 3D Rendering Type
> (0072,0520) ?

_3DRenderingType would not be a valid identifier in C or C++ because
all identifiers with leading underscore are reserved in these languages.

ThreeDRenderingType would be valid.

Regards,
Marco Eichelberg

[gunterze]

Marco,

Looks, my C++ day are too long ago ;)
Thank you for the correction!

gunter

On Jun 24, 1:37 pm, Marco Eichelberg <eichelberg_nos...@offis.de>
wrote: