Re: [ubl-ndrsc] More comments on Tag Structure paper

[Mike Rawlins <mike@rawlinsecconsulting.com>]

To be completely consistent with my example, I think what Eduardo means is he prefers:

<patientParty>
                <weightMeasure>
                </weightMeasure>
</patientParty>

to

<patientParty>
                <patientPartyweightMeasure>
                </patientPartyweightMeasure>
</patientParty>

At any rate, I think he agrees with my suggestion of omitting the object class name.

Eduardo Gutentag wrote:

> This brings up something I queried Eve about last week and she suggested I bring
> this up in this forum. Unfortunately I have not had time until now.
>
> Why are we, in an XML-centric activity, even considering things like
> <patientPartyWeightMeasure>? I can see the need for this in environments
> where the "markup" is flat, but in XML? Why not deal simply with
> <Patient>
>         <Party>
>                 <Weight>
>                         <Measure>
>                         </Measure>
>                 </Weight>
>         </Party>
> </Patient>
>
> where the hierarchy gives you all you need in terms of semantics, reusability, etc.?
>
> How can one reuse <patientPartyWeightMeasure>? No way.
>
> If there is a need to map to some other method, doing it by accumulating
> parents of a given element should be quite trivial.
>
> Can someone throw some light on this? Is there some lore behind this that
> I'm ignorant of? Seems to me the only reason this is being contemplated is
> that's the way it's always been done - and that's not good enough, IMHO.
>
> Thanks
>
> Mike Rawlins wrote:
> >
> > 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
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> --
> Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
> XML Technology Center          |         Phone:  (510) 986-3651 x73651
> Sun Microsystems Inc.          |

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