We have a query regarding referencing resources contaiend in another. Assume the scenario,
ResourceA
|- contains
|- ResourceB
|- ResourceC
And ResourceB has a reference to ResourceC.
In above case, is it mandatory for ResourceA to contain direct reference to both Resource B and C? Or is it suifficient for A to refer to B, as there is a tarnsitive reference to C already (A->B->C)?
Our intepretation of the FHIR spec is latter (i.e. transitive reference is sufficient), reading below statement from https://www.hl7.org/fhir/references.html#contained
A contained resource SHALL only be included in a resource if something
in that resource (potentially another contained resource) has a
reference to it.
However there is also another note under same documentation which is causing us a confusion, mainly as the example only demonstrates reference from current().
Implementation Note: Contained resources are still a reference rather
than being inlined directly into the element that is the reference
(e.g. "custodian" above) to ensure that a single approach to resolving
resource references can be used. Though direct containment would seem
simpler, it would still be necessary to support internal references
where the same contained resource is referenced more than once. In the
end, all that it would achieve is creating additional options in the
syntax. For users using XPath to process the resource, the following
XPath fragment resolves the internal reference:
ancestor::f:[not(parent::f:)]/f:contained/*[#id=substring-after(current()/f:reference/#value,
'#')]
Could you please help clarify this. Thanks.
The intention is that what you're doing should be allowed. However, the way the invariant is currently defined, it doesn't work - in either XPath or FHIRPath (the latter being more important). To be honest, we haven't figured out how to fully express it properly because what we're looking for is that there is a reference chain from the containing resource to all contained resources or a reference chain from the contained resources to the containing resource. There's no simple FHIRPath or XPath expression that allows for a recursive checking of this. (XPath's 'ancestor' only works on the instance, not the logical reference hierarchy.) So - what you're doing is technically non-conformant with R4. It (hopefully) won't be non-conformant in R5. And it's certainly in the spirit of what we'd intended to allow in R4...
Your interpretation is definitely correct.
I believe the xpath expression is fine, substring-after(current()/f:reference/#value, '#') extracts the Reference.reference.value field from the current node and strips the leading #. This is relative to the reference field, not the contained resource or container. The path ancestor::f:*[not(parent::f:*)] can traverse multiple steps up the ancestors to find the contained resources so it is indifferent to whether they're in the same resource or a container. It uses the constraint that contained resources can't contain more contained resources, otherwise it could be ambiguous.
Related
The current documentation of both functions reads very similar to each another:
System.IOUtils.TPath.IsUNCRooted
System.IOUtils.TPath.IsUNCPath
Both are static members of the same class, with one of them decorated inline, so I wouldn't think they are separate implementations with equivalent functionality you often find across various Delphi classes (although examples within a common class do exist in Embarcadero's standard library).
Specifically, I can't come up with a case where a path is a valid UNC path but not a rooted UNC path. So what does IsUNCRooted even mean?
IsUNCRooted only checks if the parameter starts with an UNC sequence, while IsUNCPath also checks the rest for valid path names. So a valid UNCPath is indeed also UNC rooted, but not always the other way round.
I am working with a huge 3rdparty library (Babylon JS) that will be served from its own CDN and cannot be included in my Closure Compiler run.
The library contains one object and everything defined as parts of it.
It has no externs file available so I started to write one but it is growing quickly. It would be easier to just tell Closure Compiler to not mangle any properties I am setting, including the ones I am setting on objects created by constructors on the object.
EDIT:
Added the name of the library.
The Closure Compiler has no feature that would allow you to say "don't rename any property on this object" except to disable property renaming entirely. The general idea is that it would be very easy for an "unrenamable object" to leak into a loosely typed value ('unknown', Object, etc) and disable renaming for the entire program. And that would make maintaining the expected optimizations for larger projects difficult. However, that is certainly something I would like the team to revisit at some point.
I have a set of XML schema definition resources (files). These files contain mutual import and include directives. For a specific purpose users will instantiate element definitions in a particular XSD. I would like to provide them with an excerpt that contains only the XSD resources required for the task. This means I need to trace all imports and includes to other resources recursively, until I have I set. (A Kleene Star or transitive closure).
I assume that this is implicitly done when I validate the schemata from the entry point. So there might be a call back that lists all dependencies resolved during the process that I can tap into.
The other solution I see is to use DOM and manually parse each schema for the import and include elements. This seems clunky, however.
I think the most convenient way to do this would be with an XSLT stylesheet to which you provide a list of starting points (URIs, or if you need to be careful about chameleon inclusion, namespace-name/URI pairs), and which then fetches the documents and computes the transitive closure, emitting either a list of URIs (or, again, namespace / URI pairs) or a sequence of XSD schema documents.
XQuery could also be used.
And as you suggest, DOM could also be used, with the host programming language of your choice. (I'd do it in XSLT or XQuery, myself, but that's because I do most of my programming in those languages.) Some validators may provide an API for getting a list of the schema documents consulted, or you may be able to extract that information from a validator's representation of the PSVI; APIs to XSD validation are not standardized.
Note that in the general case you need to watch out for and handle xsd:redefine and xsd:override, not just xsd:include and xsd:import.
And of course, if this is a one-shot task and the number of modules is likely to be less than fifty, it may be faster to do it by hand than by writing a program to do it automatically.
What are the main differences between the {block} tag and the {include} tag? I know they are both used for template inheritance, but does one work faster or allow for more flexibility?
The {include} function simply refers to another template file whose contents should be included at that point in the output. It is not related to any kind of inheritance, and works like a cross between PHP's include/require and a function call, in that you can pass in parameters and variables can have local scope.
The {block} function is used for Template Inheritance. While the effects could be simulated by clever use of sub-templates, the fundamental idea is very different. As explained in the documentation, a parent template can have a number of named blocks, and a child template can over-ride any or all of these, referencing them by name, with the remainder of the code coming directly from the parent template.
One way of thinking about it would be that {include} is useful if you have sections of content you want to include into multiple page structures, whereas Template Inheritance would be more appropriate if you want many pages with similar structure, but with different content in certain sections. And of course, you may well want a mixture of both.
So, I'm building a custom backend for GCC for a processor. This processor has 4 address spaces: local, global, mmm, and mmr. I want to make it such that when writing c code, you can do this:
int global x = 5;
which would cause the compiler to spit out an instruction like this:
ldi.g %reg, 5
I know that certain processors like blackfin and MeP do something similar to this, so I figure its possible to do, however I have no idea how to do it. The technique that should allow me to do this is a variable attribute.
Any suggestions on how I could go about doing this?
You can add target-specific attributes by registering a struct attribute_spec table using TARGET_ATTRIBUTE_TABLE, as described in the GCC internals documentation. The details of struct attribute_spec can be found in the source (gcc/tree.h).
This handler doesn't need to do anything beyond returning NULL_TREE, although typically it will at least do some error checking. (Read the comments in gcc/tree.h, and look at examples in other targets.)
Later, you can obtain the list of attributes for a declaration tree node with DECL_ATTRIBUTES() (see the internals docs again), and use lookup_attribute() (see gcc/tree.h again) to see if a given attribute in the list.
You want to references to a symbol to generate different assembly based on your new attributes, so you probably want to use the TARGET_ENCODE_SECTION_INFO hook ("Define this hook if references to a symbol or a constant must be treated differently depending on something about the variable or function named by the symbol") to set a flag on the symbol_ref (as the docs suggest). You can define a predicate for testing this flag in the .md .