OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Sorry if I didn't make this perfectly clear and was confusing in
contrasting Mark's position paper with what I am proposing!  What I favor
is *exactly* what you are describing here.  However, in the case of
"party" we are referring to the object class, and in the case of weight we
are referring to the representation type.  So, instead of saying something
like "patientParty" we just say "patient".  We omit the representation
type of "measure" and just say "weight" instead of "weightMeasure".

Dave Carlson wrote:

> Also, Mike, if I understand another one of your comments, the "Party"
> and "Measure" are actually datatype information that is appended to
> the tag name.  This seems really wrong to me.  The datatype of patient
> and weight are defined in the schema.  So, why not:
>
> <patient>
>   <weight>
>   </weight>
> </patient>
>
> And the schema would have:
>
> <xsd:element name="patient" type="Party"/>
> <xsd:element name="weight" type="Measure"/>
>
> where the Party and Measure are presumably defined as xsd:simpleType
> datatypes.
>
> ----- Original Message -----
> From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
> To: "Eduardo Gutentag" <eduardo.gutentag@sun.com>
> Cc: <ubl-ndrsc@lists.oasis-open.org>
> Sent: Monday, November 26, 2001 5:20 PM
> Subject: Re: [ubl-ndrsc] More comments on Tag Structure paper
>
> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC