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.