The WIJIS URI Schema.
The WIJIS Util Schema, containing generally useful components.
The WIJIS Disclosure Schema, containing components supporting assertions
about content sensitivity and nature.
The WIJIS Service Schema, containing components common to multiple Services.
The root node of the Pointer Upload Service Invocation
instruction.
Adds "deleteAllPrevious" and "transactional"
directives (intended to reflect the values
in the Invocation.)
This is a confirmation, but, unusually, it can include
error items. If the upload is NOT transactional,
then errors can be reported for the subset of
pointers that failed.
This is a very simple type. Its essential idea is that some kind of
management operation (count, download, other query) is to be performed
on the Pointers previously supplied by the Submitter whose URI
is identified in the "submitterURI" attribute.
The sole child element contains ALL Pointers,
from the requesting Submitter, found in the PointerPrecache.
This type may contain either:
A "singleSubmitterPointers" element, in which case the
"submitterURI" attribute in the "singleSubmitterPointers"
element MUST be the same as the Submitter URI specified in the
Service Invocation; or
A "multiSubmitterPointers" element, in which case *every*
pointer's "recordURI" must begin with the Submitter URI
specified in the Service Invocation.
The Service implementation may choose to use either element type.
The "submitterURI" attribute MUST be the same as
the Submitter URI specified in the Service Invocation.
The "submitterURI" attribute MUST be the same as
the Submitter URI specified in the Service Invocation.
The "submitterURI" attribute MUST be the same as
the Submitter URI specified in the Service Invocation.
When pointers data is desired to be sent by reference rater than
as literal message content, this datatype is appropriate.
This URI must be a URL as well, containing sufficient information
to permit retrieval of the data. (Likely implementations would be FTP
or HTTP URLs.)
A container for zero, one, or more than one pointers, each of
which can specify its Submitter. This is the datatype for
multi-Submitter Pointer messages.
This type also contains an optional "submitterURI" attribute.
If present, the submitterURI provides a default identity
for the Submitter responsible for sharing the records to
which the contained pointers refer. (This default can be
overridden if any contained pointer's "recordDesignator"
is a full-fledged Record URI.)
Similarly, the presence
of a "sensitivityFlags" element is taken to provide
default sensitivity information for *all* contained
pointers (and hence should be used with particular care.)
A container for zero, one, or more than one pointers.
This type (unlike the "WijisPointersType") requires
the submitterURI attribute.
This type contains pointers that do not have the capacity
to specify their Submitter.
The presence of a "sensitivityFlags" element is taken
to provide default sensitivity information for *all* contained
pointers (and hence should be used with particular care.)
A pointer to a record being shared by a
Submitter. The "recordDesignator" attribute uniquely identifies
the Referenced Record.
If no "sensitivityFlags" attribute is present, the pointer
inherits from its container's sensitivityFlags. If neither
the pointer nor its container has sensitivityFlags, they
default to "false".
Actual data contained in "content" is determined in subtypes.
In every case, the presence of the "noRecord" element is
an assertion that the record does not exist (or equivalently,
will not be provided.) It can serve as a "delete" instruction,
or as an answer to a question about the record's availability.
Any text content inside the noRecord element is considered to be
commentary without any significance for processing. Encoding
any kind of parseable processing instruction within the
element would be a violation of the design intent. (If any
requirement for processing-specific information within the
noRecord element is found, the correct approach would
be to redefine the noRecord element as some type other
than xs:string.)
A pointer that has no awareness of its Submitter,
so must inherit that from a containing (or extrinsic)
context.
Content for a single Pointer that references an existing
and available record.
This abstract supertype contains elements common to
every Pointer Content Header.
The "recordholderCaption" element is optional because the
Submitter's Recordholder Caption serves as the default.
This abstract supertype is not strictly necessary. It's
included in the model to provide a common insertion point
for any common supplemental data component definition that
might emerge. For the time being it remains empty.
This type enumerates the defined kinds of Pointers. Each type
must be declared with a trailing slash, to emphasize that it is
an abbreviated WijisURI.
To reconstitute the full URI, prepend the domain URI:
"http://wijis.wisconsin.gov/gateway/names/PointerTypes/"
The Header data defined for a Pointer to an Activity record
relating to a person.
The named person's role (suspect, witness, victim, defendant etc)
in the Activity record.
Because aliases are variable in structure, neither first, last, nor middle name
is required. this is the correct place for any kind of nickname information
Usually a title or honorific, such as "Dr.", "Rev", "Hon.", "Ras", etc
"personNickname" element is provided to hold various cognomen
information (street name, casual nickname, gang-assigned name etc)
When it seems more appropriate than using the first or last name
elements.
Ordinarily a generational specifier such as "Jr.", "Sr.", "III" etc, but also
possibly honorary titles such as "Esq." or "Ph.D."
Supplemental data defined for a Pointer to an Activity record
relating to a person.