What does max/min mean on the root element of a resource or extension?
<element>
<path value="Patient" />
<min value="0" />
<max value="*" />
...snip...
</element>
The cardinality allowed in a containing structure like Bundle? Doesn't make sense to me....
For a resource, it doesn't mean anything. For an extension, it places constraints on what the cardinality is allowed to be for a slice instantiating that constraint in a profile. For example, if an extension has a cardinality of 1..5, then if that extension is referenced inside a profile, the minimum cardinality of that constraint element must be at least 1 and the maximum no more than 5. Most of the time this will just be used to indicate whether the extension will be allowed to repeat or not.
Related
it is possible to slice a string list, like the element line on the Address? I'm trying to do something like that: https://simplifier.net/redenacionaldedadosemsaude/brendereco, but when I generate my IG, my sample resource does not validate the lines.
my resourse example address element:
<address>
<use value="home"/>
<type value="physical"/>
<text value="1003 Healthcare Drive, Northfield MN" />
<line value="street"/>
<line value="Healthcare Drive"/>
<line value="1003"/>
<line value="neighborhood"/>
<city value="Northfield"/>
<state value="MN"/>
<postalCode value="12345123" />
<country value="Brasil" />
</address>
Errors I got on my IG:
When you slice and declare a discriminator, then every slice needs to establish a value for that discriminator. You sliced by Address.line.value by value. That means that each line slice needs to specify a required value set binding, a fixed value or a pattern. (And the constraints declared by each slice can't overlap.) You only declared a required binding on one of the slices. The street, number, complement and neighborhood slices are unconstrained. That's not allowed.
Given that, realistically, you can't define value sets (let alone fixed values or patterns) for those elements, I don't think slicing is going to be possible with just 'value'. If you need to distinguish between different repetitions of Address.line, you're going to need to put an extension on them that indicates what type of line they are.
Also, it's not clear that you're using 'line' correctly. An address line is a string of text that appears on a separate line. It's not just a distinct part of the address. Unless streetType, street, number, complement, etc. all need to appear on separate lines, you can't create separate repetitions of 'line' for them. If you want to break out the parts of the address, you need to use extensions. There are already standard extensions for most 'parts' of an address - you can see them here: https://build.fhir.org/datatypes-extras.html#Address
Using XSD schema validation 1.0 I want to verify an element has at least one attribute specified.
For example, a simple element like this:
<foo a="1" b="2" c="3" />
I want to verify that at least attribute b or c is specified. But note that both can also be specified--they're not mutually exclusive.
I tried using a key along the lines of:
<xs:key name="AttributeSpecified">
<xs:selector xpath="." />
<xs:field xpath="#b|#c" />
</xs:key>
but it fails when both attributes are specified (because multiple results are returned).
Can it be done?
This is not possible in XSD 1.0. It might be possible in XSD 1.1.
I am a fan of XML Schema, but I would not choose it for this type of validation. You might be able to make it work using XSD1.1 but if your requirements became just a little more complex you could end up with some horrible-looking constraints.
On the other hand, an XPath expression can elegantly express any constraint you can think of, and you would not need to bend the language to make it work.
I'm trying to figure out how to fully specify a sliced element. If I'm reading the spec right, nameReference is the only place where a "sub element" of a slice can declare which slice it's "on".
So, if telecom is sliced by use and system and I want to specify a constraint on home phone, I have to fix use and system to those values and then add my constraints on that slice.
Consider:
Resource Example ElementDefinition attributes
================================ =====================================================================
<Patient> name="Patient"
... snip ...
<telecom> name="HomePhone"
<system value="phone" /> name="HomePhone.system", nameReference="HomePhone", fixedCode="phone"
<use value="home" /> name="HomePhone.use" , nameReference="HomePhone", fixedCode="home"
<value value="5551234567" /> name="HomePhone.value" , nameReference="HomePhone"
</telecom>
... snip ...
</Patient>
In most examples, it appears that a dotted notation of Name has been used (as I've placed in the example). But the specification doesn't require this and provides no format that could be reliably parsed.
The problem is: nameReference and fixed[x] are mutually exclusive. What's the correct way to handle this??
Repetitions in an instance don't "declare" what slice they're part of. They simply declare the appropriate value for what ever element(s) are the discriminator for the slicing process. nameReference isn't involved at all. On the definition side, association is simply handled by name. So HomePhone.system is associated with HomePhone simply by the name and by sequential proximity. The dot-notation is required. We could probably be a bit more explicit about that though, so feel free to submit a change request.
I'm adding Apple Event scripting to my application. I would like to be able to use both of the statements below on it:
-- Every instance of MyObject in the app
every MyObject
-- Only the instances of MyObject the user has selected
selected MyObjects
These are relevant excerpts from of my sdef file:
<dictionary>
<suite ...>
<class name="application" code="capp" description="Top-level scripting object" plural="applications" inherits="application">
<cocoa class="MyAppClass" />
<element type="MyObject" access="r">
<cocoa key="myobjects" />
</element>
<element name="selected MyObjects" code="ABCD" type="MyObject" access="rw">
<cocoa key="selectedMyObjects" />
</element>
</class>
<class name="MyObject" code="ABcd" inherits="item" plural="MyObjects">
...
</class>
</suite>
</dictionary>
When I call every MyObject, it returns a list of objects, as expected. But when I call selected MyObjects, the Script Editor selects the "MyObjects" portion and complains:
Syntax Error
Expected end of line, etc. but found plural class name.
How can I achieve what I'm looking to do?
Your design is wrong. See the Scripting Interface Guidelines for a somewhat thin but better-than-nothing outline of good UX practices.
The correct idiom is to define a selection property, typically on application and/or document. This may be read-write or read-only, depending on what's appropriate to your application.
The selection property's value is either:
A single bespoke object specifier that identifies all of the currently selected objects e.g.:
selection of application "Foo"
or
selection of document X of application "Foo"
Some of the better Carbon-based apps and the occasional Cocoa app use this approach, which allows users to perform powerful queries such as:
get (name of every MyObject of selection of document X)
delete (every job whose status is completed)
but requires more work for you to implement.
A list of single-object specifiers, each identifying one selected item, e.g.:
{thing B of document X of application "Foo",
thing E of document X of application "Foo",...}
This is less powerful, since users cannot manipulate all of the selected items in a single command but must instead iterate the list processing each item one at a time, but is cheaper for you to implement. Cocoa Scripting being somewhat lame and inflexible even at the best of times, and pretty damn hopeless at moving/duplicating/deleting more than one object at a time, this is the most common approach in Cocoa-based apps.
Update your sdef file with this property:
<property name="selection" code="ABCD">
<cocoa key="selectedMyObjects" />
<type type="MyObject" list="yes" />
</property>
For an example of the first (better) design approach, take a look at Script Editor's own dictionary. For an example of the second, see Mail's dictionary.
(Tip: To view a dictionary in Script Editor, choose File>Open Dictionary and select the appropriate item from the list. To export that dictionary as an SDEF file, just make sure the dictionary viewer window is frontmost and choose File>Save As.)
Let's say I have nodes like so:
<Params>
<Param val="C" />
<Param val="D" />
<Param val="A" />
<Param val="B" />
<Params>
If I select the Descendants of Params is the order always preserved? I want C to always be first when I iterate through the ordered list that I'll be dropping these into. Or do I need to come up with a different solution for ordering nodes? I'd like to stay away from numbers (order="1", 2 etc.) so any suggestions would be great.
The documentation for the Descendants property says:
Returns a collection of the descendant elements for this document or element, in document order.
So the answer is yes, they will be returned in the same order they appear in the original XML.