[ubl-ndrsc] More comments on Tag Structure paper

[Mike Rawlins <mike@rawlinsecconsulting.com>]

I basically favor Mark's option 1, but with some variations,
completions, and comments.

Option 1 is incomplete in that it specifies how element (etc.) names are
to be constructed using the assigned representation term, but it doesn't
say anything about names for the component parts.  For example, we might
have a basic information entity of patientPartyWeightMeasure.  The
approach only gives us a tag for the "content" part of the information,
but not for the unit of measure associated with every item that has a
representation type of measure.  Assuming that the "content" is the
element content and other components of the representation term are
expressed as XML attributes (an approach we might want to consider, but
that's a different discussion), do we say:

<patientPartyWeightMeasure uom="KGM">140</patientPartyWeightMeasure>

or

<patientPartyWeightMeasure
unitOfMeasure="KGM">140</patientPartyWeightMeasure>

or

<patientPartyWeightMeasure xxx="KGM">140</patientPartyWeightMeasure>

where xxx is something else as yet undefined?

I also favor an approach where the "Object Class" portion of the name is
omitted for the children.  For example, instead of having:

<patientPartyDetails>
    <patientPartyNameText> ...

we have

<patientPartyDetails>
    <nameText>

The latter approach is much less verbose and allows an XML schema
representation where the CC might be a type (like party) and all we need
to do is declare or extend the type for the BIEs (like patientParty).
Otherwise, we have to declare each and every <mumblePartyNameText> in
the schemas and have practically *no* reuse at the XML syntax level.

Finally, though I don't have as strong preferences on this and can't
provide as good a rationale, I favor dropping the representation term
part of the name unless it is needed to avoid duplication.  Saying
"partyNameText" instead of "partyName" seems overly verbose and adds
little value if the information is understood in context.  A developer
can always look at the element or type definition if the data type is
not clearly understood from a knowledge of the business data.

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