I am trying to understand which attributes are required and which are not.
As far as I understood you look at the corresponding IOD to your SOP class and then check which modules are mandatory or not. Then in the modules you can see which attributes are required and which are not.
For example if my SOP class is multi frame ultrasound images, I look at the corresponding IOD, which can be seen on this page:
https://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.7.html
Then I see a module called "Clinical Trial Subject", it's usage says U, which means it's optional. However when I check the module on this page, I see multiple attributes which are listed as type 1, which means these attributes are required.
I was wondering if I should add these attributes in the DICOM header or if I can ignore it because in the IOD it says this module is optional.
What this means is that the module itself is optional, but if you have the module then those elements are mandatory within the module.
This makes sense logically: obviously a single study may, or may not, be a clinical trial - hence the clinical trial module is optional.
However if a study is part of a clinical trial, then there are definitely some information you always want to know. So those elements within the trial module are mandatory.
Related
How PIP and whole ABAC engine should behave in case if it can't resolve attributes.
There are several cases:
Destination object using which we are resolving attribute is not found
Attribute can't be resolve because provided attributes not sufficient to request addition information. Like if we passed single userId and resource name without id.
If during attributes resolution chain (when some attributes depends from another) something has been missing that make target attribute resolution impossible.
ABAC is a broad concept that does not specify this kind of low-level behavior; and it is difficult to give a universal best practice for all ABAC frameworks, since there is a growing bunch of them possibly quite different: some of them are standard (eg. OASIS XACML, NIST NGAC), others non-standard yet generic (eg. OPA), others product-specific (eg. Kubernetes ABAC).
It is easier to give tips for the XACML (3.0) standard since the specification is more mature:
§ 5.29 says: In the event that no matching attribute is present in the context, the MustBePresent attribute governs whether this element returns an empty bag or “Indeterminate”. See Section 7.3.5. (The MustBePresent is defined on AttributeDesignator elements in your XACML Policy. An AttributeDesignator is a reference to an attribute, for which, in your case, a PIP should be called if the attribute is not available in the current request context.)
§ 7.3.5 gives more details: If the attribute is missing, then MustBePresent governs whether the attribute designator or attribute selector returns an empty bag or an “Indeterminate” result. If MustBePresent is “False” (default value), then a missing attribute SHALL result in an empty bag. If MustBePresent is “True”, then a missing attribute SHALL result in “Indeterminate”. This “Indeterminate” result SHALL be handled in accordance with the specification of the encompassing expressions, rules, policies and policy sets. If the result is “Indeterminate”, then the AttributeId, DataType and Issuer of the attribute MAY be listed in the authorization decision as described in Section 7.17. However, a PDP MAY choose not to return such information for security reasons. [...] Regardless of any dynamic modifications of the request context during policy evaluation, the PDP SHALL behave as if each bag of attribute values is fully populated in the context before it is first tested, and is thereafter immutable during evaluation. (That is, every subsequent test of that attribute shall use the same bag of values that was initially tested.) The last sentence means in particular that if PIP attribute resolution results in an empty bag and MustBePresent=False, you should keep the attribute value as empty bag for the rest of the policy evaluation, i.e. NOT try to call the PIP again for the same attribute (risking a value change) in the same context.
§ 7.19.3 specifies how the PDP should include the information about a missing attribute in its response.
Beware that the final result is also affected by combining algorithms in XACML. E.g. even if an AttributeDesignator returns Indeterminate because of a PIP error in a child Rule/Policy(Set), algorithms of the enclosing policy like deny-unless-permit (resp. permit-unless-deny) may return Deny (resp. Permit) regardless.
That's what the standard says, then, there is implementation-specific behavior. In AuthzForce XACML implementation for instance, we distinguish the following cases while trying to be as XACML compliant as possible:
If PIP internal error occurs during attribute resolution (connection issues, misconfiguration, missing dependency, etc.), then the AttributeDesignator evaluates to Indeterminate regardless of MustBePresent, because we consider this critical, and we add the info Missing attribute XXX; we also add info about the cause, e.g. Missing dependency: attribute YYY if PIP requires some attribute that was missing from the context to do its job (e.g. missing dependency: attribute 'subject-id' if the PIP fetches the user's roles but requires the subject-id attribute to do that, which is missing).
If PIP attribute resolution is done error-free but no value found, in other terms the result is empty (e.g. some PIP fetches the user's roles successfuly from a database but gets an empty list because no role has been assigned to the user.), then the AttributeDesignator evaluates to an empty bag if MustBePresent=false, else (if MustBePresent=true) returns Indeterminate with the info Missing attribute XXX.
The interaction between the PDP and the PIP is not specified in the XACML standard. It is down to each implementation (AuthZForce, Axiomatics...) to determine how they handle each case.
Generally speaking, there are 3 errors that can occur when using a PIP:
Connection issues: the target PIP (e.g. an LDAP server) cannot be reached
Mapping configuration issues: the mapping for the attribute is invalid. For instance you are retrieving an attribute from a non-existing SQL table or column.
Data issue: there is no data to be read in the underlying source
In addition, there is another possible issue: the keys used in the mapping (e.g. username) has no value at all. In this case, it is clear that the mapping (e.g. to retrieve a role) will not be invoked at all.
Points 1 and 2 could lead to Indeterminate. This helps the administrator troubleshoot the installation.
Point 3 should lead to NotApplicable for that branch that uses the attribute. If there is no value, then so be it. Why would there necessarily be a value?
I hope this helps,
David.
With ValueTuple in C# 7, it is now possible to write methods and properties that return or consume composite objects without explicitly declaring a type. These named tuples can however be potentially confusing when no documentation is provided.
As the primary and probably most convenient way of documenting libraries is by using XML documentation, is there any way using XML documentation to provide a description of the variables in a named tuple?
I know the obvious solution is to declare a type and document it accordingly. However, granted that due to some 'reasons' that cannot be done, is it possible to XML document the data members in a ValueTuple?
NB: A similar question was asked before the advent of the ValueTuple.
C# has no special syntax for documenting named elements of a tuple, you will have to use the normal <returns> and <param> elements and explain in words what each named element contains.
Though there is a proposal for adding this capability to the language.
In the example I made every object of the type "Folder" have an array of type "File" with the name "content" a size of "n" as a private attribute (just saying my understanding of it to make sure that I am not already wrong there). That's how I see it in most examples but I never understand what "n" now is. Is it another attribute of the "Folder" object or is it something that we specify in another part of an UML diagram or something else completely?
What I am trying to achieve is that every object of the type "Folder" has an additional attribute that specifies the size of the "content" array.
Of course, you can not only write 0..*, but use any concrete number, too. If that number has some external definition, you can use there n, as you have it.
The external definition means "not defined by class diagram elements, except notes". Everything that you need to be said on a class diagram page, but can't because of the UML limitations, should be put in a note.
So, n can be defined in appropriate note on the page or in some different document or both.
As #Kilian had mentioned, in the case of some more complicated dependencies of such variables you can use constraints. This way seems to me the most powerful.
But if n has no objective definition or dependency, but is a simple variable that can have any meaning, then it will be correct to use a rule, such as 0..*, or 1..*, or maybe 3..5, according to the reality you are working with.
I am currently teaching myself RDFa Core 1.1 after successfully learning RDFa Lite rather easily. Straight to the point, I can't understand two things: the difference between property and rel, and the difference between resource and about.
Please explain to me in simpler terms than the spec :)
property vs. rel:
Both attributes indicate a predicate of a triple, e.g. rel="http://purl.org/dc/terms/creator, which is the predicate ... has as a creator: ....
The difference is, from where they take their object. Slightly simplified, the rules for property are: The object is taken ...
from a valid content attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid resource attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid href attribute or, if this is not present in the tag,
(if no datatype attr is present in the tag:) from a valid src attribute or, if this is not present in the tag,
from the inner content of the element started by the tag.
Slightly simplified, rel differs in two aspects:
It takes its object only from a resource or a href or a src attribute.
It takes its object not only from an attribute of the same tag, but may also take it from descendant tags. The whole mechanism is called "chaining": "This is the main difference between #property and #rel: the latter induces chaining, whereas the former, usually, does not." 1 Usually, but property can induce chaining if used with typeof (cf. 2).
about vs resource:
about is the attribute to indicate the subject of a triple. The rules for resource are more complicated: It may indicate a subject or an object, and chaining plays a role here, too.
IMHO, chaining is the most complicated and confusing part of RDFa (and does not give you more than syntactic sugar). I would avoid chaining. This is possible by avoiding the attributes rel, rev, resource and typeof, which brings some further simplification at the same time. Thus, I use only the following attributes:
about for the subject
property for the predicate
content or href or src (or the inner content of the element) for the object, following the rules outlined above
lang for a language tag for object literals, e.g. lang="en"
datatype for a datatype tag for object literals
prefix (but only once in a document), so that I can abbreviate URLs by prefixing, e.g. property="dc:creator"
vocab (rarely and at the most once in a document), so that I can abbreviate URLs implicitly, e.g. property="creator".
(And I use the tag <base href="..."> to indicate the URL base value of the document.)
This is a strict, safe, easy-to-use and easy-to-parse subset of RDFa and allows to express any triple you want.
I would personally recommend to ignore / avoid using rel and about, they are not really necessary to write RDFa if you follow the rule of thumb that you should not try to be too smart by stuffing as many attributes as possible in a given HTML element. There are around for backward compatibility reasons. The other attributes from 1.1 are worth learning though: content and datatype.
Stephan's advice is in general conformance with RDF Lite 1.1, which does not include #rel or #about for precisely these reasons.
Another good rule of thumb is to not try to include markup of more than one entity on a given element, which was often an example of specifying an images license.
#property and #rel are very similar to each others, but served different purposes in RDFa 1.0, but this was confusing, even for experts. (Formerly, #rel was used for specifying objects which are other nodes, and #property was used for specifying literal values. While there are some remaining differences, but sticking to non-clever markup, you can do everything with #property that you could do with #rel.
Similarly, #about can be avoided to just use #resource. The difference is that #about sets the current subject and #resource the current object, but for child nodes the parent object (taken from the parent's current object becomes the current subject. There were another minor differences concerning the presence of #typeof, but if you only use #resource, it pretty much does what you want.
To summarize the best practices from RDFa Lite 1.1 you can also check out the RDFa 1.1 Primer:
stick to #vocab, #prefix, #property, #resource, and #typeof
avoid making more than one statement in a given element
I have set of custom attributes, my logic reflects over applied attributes on specific properties. Part of the logic was trying to rely on the sequence in which the attributes are applied in he source code, however what I found after decompiling few timers that the C# compiler doesn’t put the attributes in IL in the same sequence as it appears in the source code. Any insight on this? I am not able to find any information about this in MSDN.