For a given implementation scenario is it acceptable to limit how resources are used within the system in ways not described by resource profiles.
A number of scenarios :
- explicitly prohibit the use of <contained> resources
- explicitly prohibit the use of <modifierExtensions>
- explicitly prohibit the use of the narrative <text>
Validation on the system could clearly implement the above, but is there away of advertising this restriction on say an "implementation conformance profile"?
Profiles don't say anything about which resources are used general, as in "which resource are supported by a FHIR endpoint or client", since that would be for that server or client to decide. And they report such capabilities in their Conformance statement.
Profiles can limit the resources involved when communicating data between partners: For example, an Observation may normally refer to Patient, Group, Device or Location in its 'subject' property. You may limit these to a subset, and by doing this consistently across Resources, you are effectively restricting the set of Resources exchanging trading partners need to "know" about when they use that Profile (and only that profile).
I think your second bullet misses some text, so I can't comment on that one.
The spec says about Narrative:
Resources SHOULD always contain narrative to support human-consumption as a fallback. However, in a strictly managed trading systems where all systems share a common data model and additional text is unnecessary or even a clinical safety risk, the narrative may be omitted."
If you look at the base profile definitions of a given resource (look at http://www.hl7.org/implement/standards/fhir/observation.profile.xml.html) for example, you'll see that Observation.text is defined there with cardinality 0..1, you may profile this to 0..0 to make this explicit in your profile.
Here's an example Profile showing the tools there are, including Lloyd's suggestion to use XPath:
<Profile xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../schema/profile.xsd">
<!-- stuff removed -->
<structure>
<type value="Observation"/>
<name value="MyConstrainedObservation"/>
<publish value="true"/>
<!-- again, elements left out -->
<element>
<path value="Observation" />
<constraint>
<key value="shorttext" />
<severity value="error" />
<human value="Must be short text" />
<xpath value="string-length(f:text) < 100" />
</constraint>
</element>
<element>
<path value="Observation.modifierExtension"/>
<definition>
<min value="0" />
<max value="0" />
</definition>
</element>
<element>
<path value="Observation.text"/>
<definition>
<short></short>
<formal></formal>
<min value="0" />
<max value="1" />
<condition value="shorttext" />
</definition>
</element>
<!-- elements left out -->
<element>
<path value="Observation.subject"/>
<definition>
<type>
<code value="Resource(Patient)"/>
<aggregation value="bundled" />
<aggregation value="referenced"/>
</type>
</definition>
</element>
<!-- more stuff -->
</structure>
</Profile>
This profile first defines an XPath constraint limiting the length of a text (just as an example), and goes on to limit the cardinality of Observation.modifierExtension to 0..0, effectively forbidding its use. Furthermore, it limits Observation.subject to only reference Patients (thus you might avoid the use of Device etc. in your exchanges) and specifies that those Patients can only be referenced or bundled (in a message, document or transaction), but may not be included using .
Obviously, what I did here can be done with Observation.text and Observation.contained too. You have both structural (cardinality) and executable (xpath) means to limit the content at your disposal.
I believe you would add this to your conformance document
In profiles, it's also possible to constrain any of these elements through the use of Profile/structure/element/definition/constraint. For example, to prohibit narrative on Patient, you would define a Profile with a structure of type "Patient" and on the root "Patient" element, include a constraint with the xpath "not(f:text)"
This would still need to be done on a per-resource basis though.
Another option would be to define an isModifier extension on your Conformance resource which declares that you don't support isModifier or text or whatever on any resources. Though in practice, that's just going to mean most systems won't know how to read your Conformance resource and thus won't know how to talk to you at all.
Some advice:
Keep in mind that any such restrictions are greatly going to limit your ability to interoperate with the broad community, though they could potentially be appropriate in very limited environments.
With isModifier, there's general recognition that most systems will reject instances containing an isModifier they don't recognize, so if you don't recognize any modifier extensions, rejecting instances that contain them doesn't require any special declaration - it's normal behavior.
As for text, it may be better to place a constraint that says that narrative must be generated rather than prohibiting it altogether. Generated narrative can be safely ignored and you're much more in the spirit of FHIR conformance doing that than rejecting instances with any narrative at all.
Related
I have a GSchema defining some flags like so:
<flags id="org.example.program">
<value nick="ENGLISH_WORD" value="1"/>
<value nick="ANOTHER_WORD" value="2"/>
</flags>
However I have been informed by a translator that these are not processed by gettext or offered in the .pot file. Is there a way I can mark these as translatable?
The default values can be translated but the translations are substituted from .mo files at runtime. You have to put the textdomain in the attribute "gettext-domain" of the "<schemalist>" resp. "<schema>" element. You also have to put the locale category into the attribute "category" of the "<default>" element. Read the paragraph "Description" in https://developer.gnome.org/gio/stable/GSettings.html for more information.
I recommend that you examine the sources of a recent Gtk application and see how the different components are localized. GNU gettext has recently been improved to offer better support for localizing desktop applications and therefore the process is currently evolving. In particular, you usually no longer need intltool.
So we're using basic Ant 1.9.4, with a little use of 1.9.1's new if/unless attributes. For example,
<project xmlns:if="ant:if" xmlns:unless="ant:unless">
.... miles and miles of XML ....
<jar ....>
<service ....>
<provider classname="a.b.c.X" if:true="${some.flag}"/>
<provider ..../>
</service>
<fileset>
....the stuff in here will matter shortly....
</fileset>
</jar>
with some.flag always set to true or false, never left unset, and never set to any other value (assigned inside a property file read in earlier, if that matters), and it works wonderfully, giving us exactly the behavior we need. Joy!
More recently, we tried to make some of the jar task's fileset entries a little smarter, such as
<fileset dir="somedir">
<include name="optional_file" if:true="${some.flag}"/> <!-- same property name as before -->
</fileset>
With this syntax, we get an error "A zip file cannot include itself", with a line number pointing to the start of the jar task. This is obviously bogus syntax. However, changing this second if:true to simply if out of desperation -- and making no other changes -- avoids the error and gives us correct flag-based optional inclusion behavior.
What's going on here? Is the new syntax simply unavailable in <fileset> and/or fileset's nested <include> blocks?
As an experiment, I tried using an if:true or if:set attribute as appropriate in a few other useful places. Some places it worked perfectly. Some places I got some bizarre nonsense error, clearly the kind of thing that a parser prints when it's gone off the rails. Each time, reworking if:set="$(foo}" into if="foo" and if:true="${foo}" into if="${foo}" got back to the desired if-then behavior. So it's not a blocking problem, but we'd rather have the self-documenting :condition if we could.
I couldn't find mention of any such restriction in the Ant manual, but the manual describes the if/unless syntax in at least two different places using different descriptions. (I'm not sure where they are due to the manual's use of HTML frames; every URL shows up as index.html. Anytime I refer to the manual it feels like I'm browsing like it's 1999, baby! *does MC Hammer slide out of the room*)
Since Ant 1.4, <include> and <exclude> elements nested under <patternset> elements have supported if and else attributes. Each <fileset> has an implicit <patternset> nested under it, so the if and else attributes are available to it...
<condition property="some.flag.istrue">
<istrue value="${some.flag}"/>
</condition>
<fileset dir="somedir">
<!-- The "if" below is different than "if:true". -->
<include name="optional_file" if="some.flag.istrue"/>
</fileset>
In the above example, the if in <include> is an ordinary Ant attribute in the "default" Ant XML namespace. On the other hand, if:true is in the ant:if XML namespace.
The namespaced if:true doesn't work well with <include> elements. If the value provided to if:true doesn't evaluate to true, then Ant behaves as if the entire <include> element never existed. This is bad because Ant takes empty patternsets to mean "match every file". This is likely why you received the "A zip file cannot include itself" error; the <fileset> was likely containing the destination JAR file.
Stick with the plain if and else attributes for <include> and <exclude> elements and things should work.
I've just started generating Groovydoc for a library I'm working on. However, the preponderance of java.lang and java.util and other common package prefixes in the method signatures is obscuring the real intent of the methods. I'd like to be able to generate the Groovydoc without these. As in the (made up) example:
List flatMap(Iterable itr, f)
rather than:
java.util.List flatMap(java.lang.Iterable itr, f)
(Some of my real examples are worse, having three or four something.entirely.Obvious arguments plus the return value.)
In Javadoc I'd achieve this with the -noqualifier option. No similar option is listed for groovydoc --help however.
Is there a way to do this with Groovydoc? If not, has anyone come up with any other reliable way to do this? (My fallback, which I haven't had a chance to try yet, it to attempt post-processing the generated documentation with Ant's replace task - but I wondered if there is a better way.)
The following Ant task hack seems to produce reasonable results for Groovy 2.4.3's Groovydoc output. (At least I haven't found anything it has broken yet.)
<replace dir="build/doc/groovy/api">
<replacefilter token="(java.lang.Object " value="("/>
<replacefilter token=", java.lang.Object" value=", "/>
<replacefilter token="java.lang." value=""/>
<replacefilter token="java.util." value=""/>
<!-- ... add more here ... -->
</replace>
Still wondering if there's a better way.
We would like to use the XLIFF format as base for translating certain texts from German into French and Italian. (The translations will be performed with SDL Trados.)
From the specification, there seems to be precisely one target language per XLIFF file, but additionally there can be specified further "alternate languages". Specifying two target languages would therefore be possible from the spec:
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file source-language="de" target-language="it">
<body>
<trans-unit id="hi">
<source>Betrieb</source>
<target>Divisione</target>
<alt-trans>
<target xml:lang="fr">Site</target>
</alt-trans>
</trans-unit>
</body>
</file>
</xliff>
Is this using XLIFF in the expected sense? Or would it be better to produce two documents, one with target language fr and another one with target language it? (I don't like the repetition)
<alt-trans> is not intended for having <target>s in more than one language in each trans-unit; it's rather intended for translation match be it translation memory, machine translation matches, or simple an outdated target string which needs to be updated according to most recent changes in the source string. Having said that, in some cases <alt-trans> is perceived as a workaround for translating what the industry calls "adaptive languages" (French for Canada is often adapted from French translation) without having separate files. As a localization practitioner who has to deal with Xliffs from various sources and presented in various schemas, I recommend to avoid this hack. It is more common and accepted to use the <file> tag to embed trans-units for multiple languages in one Xliff file:
<?xml version="1.0" encoding="utf-8" ?>
<xliff version="1.1" xml:lang='en'>
<file source-language='en' target-language='de' datatype="plaintext" original="Sample.po">
...
<body>
<trans-unit id="1" restype="button" resname="IDC_TITLE">
<source>Title</source>
</trans-unit>
<trans-unit id="2" restype="label" resname="IDC_STATIC">
<source>&Path:</source>
</trans-unit>
...
</file>
<file source-language='en' target-language='fr' datatype="plaintext" original="Sample.po">
<trans-unit id="1" restype="button" resname="IDC_TITLE">
...
</body>
</file>
</xliff>
I work for a translation agency.
I have not seen multilingual xliff files yet. So to make your and your agency's life easier, I would build individual files.
Also other tools like e.g. CenShare create individual files.
And it makes it easier to hand it over to different translators.
According to the OASIS wiki:
An XLIFF document is normally a bilingual file. It has one source language (the language of the original extracted file), and one target language.
However, the <alt-trans> elements can be in language other than the source or target one.
Source: How many languages can I put in an XLIFF document?
I'm trying to use <concat> as a resource collection in a <zip> task and, according to the documentation, this should work. I'd like to do this because some of the files I want to include in the zip need to have some properties expanded, so I will also add a <filterchain> to the <concat> to do this. I'd prefer to do it directly rather than copying to a temp location (with property substitution) and including the copy in the zip file.
However, I can't seem to get <zip> to correctly use the <concat> element.
A simplified example of what I have so far:
<zip destfile="target/dist.zip">
<concat>
<fileset file="CHANGES.txt" />
</concat>
</zip>
This creates a zip file containing several directories all named concat (C: (obviously this is on a Windows machine).
What am I missing?
A colleague and I came up with the answer by looking through the <zip> and <concat> source. There are really two answers:
<concat>'s implementation of the ResourceCollection interface is odd, but we understand why.
There's a way around that.
For #1, while <concat> is a ResourceCollection (like FileSet), under the hood it returns as the name of single Resource it contains a hard-coded value:
"concat (" + String.valueOf(c) + ")";
Look familiar?
The name of resources is normally ignored--except by <zip> and its related tasks, which uses the resource name as the ZipEntry name. Since <concat> returns the odd-looking name, that's what we get in the zip file.
I haven't quite figured out why I get multiple entries, but it doesn't matter: the observation leads to a convoluted solution.
Since I know the name of the ZipEntry I want to create, I can use a <mapper> to give the <concat> resource a name. Here's what I came up with in all its glory:
<zip destfile="target/distribution.zip">
<fileset dir=".">
<exclude name="target/**" />
<exclude name="CHANGES.txt" />
</fileset>
<mappedresources>
<concat>
<fileset file="CHANGES.txt" />
<filterchain>
<expandproperties />
</filterchain>
</concat>
<mergemapper to="CHANGES.txt" />
</mappedresources>
</zip>
As my colleague says "In Ant every problem can be solved using a mapper."
This only works for Ant 1.8+ because <mappedresources> was added in that release.
I'm going to post some comments to the Ant mailing list and suggest a couple of enhancements:
Allow a resource name to be specified as an attribute on <concat> when it's being used as a ResourceCollection.
Throw an exception (and don't create a synthetic value) if getName() is called without having a value specified.
Finally, though not directly related, I do wish <expandproperties> could take a <propertyset> so I can control which properties get substituted.
Do you want the final zip to contain a single file or multiple files? As far as I can see, using concat (when done successfully, which isn't done above) would produce a single file, the result of concatenation of all files in the resource collection.
If you want multiple files rather than concatenation, I think intermediate copy is what you'll need.
From Ant manual for the concat task:
Since Apache Ant 1.7.1, this task can
be used as a Resource Collection that
will return exactly one resource.