Re: [ubl-ndrsc] Absence of Data

[Mike Rawlins <mike@rawlinsecconsulting.com>]

"Eve L. Maler" wrote<snipped>:

> (What is PESC?)

Postsecondary Electronic Standards Council, a group concerned with promoting and
creating standards for the electronic exchange of data in higher education.

> >1. Absence of data - If an element is defined as OPTIONAL (minOccurs
> >attribute value of zero) and the element does not occur in an instance
> >document, semantics SHALL NOT be interpreted from the element other than
> >
> >that the originator of the instance document and did not include it.  No
>
> Try as I might, I can't make sense of the last bit about the
> originator.  Is there a word missing or extra?  Also, the notion of
> "semantics being interpreted" sounds a bit fuzzy to me.  Would it be
> clearer to say something like "The absence of an optional element in an
> instance SHALL NOT be interpreted as a signal that the element, if present,
> would have had a null value" or something like that?  A concrete example of
> how an absent element could be misinterpreted would be helpful.

Even assuming that this group agrees with these notions, I think we should probably
come up with our own phrasing instead of copying from the PESC document.  The gist
of what we intended was that if the data isn't present, all you should imply is
that we're not saying anything about it.  I'll give you two examples:

In one case, two address lines for street are sent.  In a subsequent document, only
one line is sent.  All that should be interpreted is that a second line was not
sent, not that the existing second address line should be deleted.

As a second case having to do with a numeric field, say the temperature at which a
refrigerated container should be held.  If the element is not sent, we're not
specifying a temperature.  One should not interpret the absence of a temperature as
a default value of zero, and therefore hold the container at zero degrees.

> Also, we should separate out the schema-design advice from the generic
> advice to those who have to interpret an instance that uses a schema
> designed according to our guidelines.  In fact, the interpretation advice
> should perhaps offer brief documentation boilerplate that should be
> attached to all elements that are in this situation; after all, it's not
> advice about how to properly structure an instance (like our advice about
> processing instructions etc. will be), but rather how to properly
> understand it.

I get the idea, and agree in principle.  In practice, people are going to put all
sorts of interpretations on what they do or don't receive.  However, I think it
will help if we at least state our assumptions and intentions.

> >2. Zeroes - Zeroes, when appearing in a numeric element in an instance
> >document, SHALL be interpreted as a zero value.
>
> Should we qualify numeric by saying listing the built-in datatypes this
> applies to and saying it also applies to any datatypes derived from them?

Fine by me.

> >4. Nullability - In certain cases, it MAY be desirable to convey that an
>
> I don't believe that this is a legitimate use of the uppercase MAY (it's
> not being used in a normative sense).  I usually use "might" in these
> circumstances, or it could say "Where a schema is designed to be nillable, ..."
>

OK.

>
> >element has no value (a null value) rather than indicating that it has a
> >
> >value of spaces or that it is not present in a document.  In these
> >cases, the originator of the instance document SHOULD convey explicitly
> >that an element is null.  An example is an address update for a
> >previously transmitted address.  The previous address had two address
> >lines, whereas the current address has just one line.  The originator of
> >
> >the document indicates that the second address line is removed by
> >indicating that the element is nulled as follows:
> ><addressLineTwo xsi:nill="true"></addressLineTwo>
> >
> >To support this the addressLine element in the schema is defined as
> >nullable via:
> >
> ><xsd:element name="addressLine" type="xsd:string" nillable="true"/>
> >
> >When this type of nullable semantics are desired, the "nill" and
> >"nillable" attributes SHALL be used (as opposed to spaces for strings or
> >
> >zeroes for numerics).   The "nillable" attribute SHALL NOT be used in
> >element declarations with a minOccurs of greater than zero.  When there
> >is a requirement that an element be OPTIONAL and not appear in an
> >instance document, the minOccurs attribute with a value of zero SHALL be
> >
> >used in the element declaration.  By default, any element defined in
> >analysis as having a minimum occurrence of zero SHALL be represented in
> >the schemas as nullable.
>
> To be honest, the whole nillable thing is new to me, and I recall that the
> XSD working group was sharply divided on it (with only the relational DB
> people on the "for" side).  Does it really buy us anything over
> application-specific token values like "none" or "no" or whatever?
>

The folks I was working with in PESC came up with an example that went something
like this.  We want to update a student's address.  The student has moved from a
dormitory (with a room number), into a house.  To explicitly say that the student
no longer has a room number, they decided the best way to say it was as:

<roomNumber xsi:nill="true"/>

Like you, I don't know if it buys us anything that sending "none" in roomNumber
would do, other than the "none" needs to be an agreed upon implementation
convention whereas the xsi:nill="true" is very explicit on what it means.

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com