[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] More comments on Tag Structure paper
Now you're talking. This I can go with. Mike Rawlins wrote: > > 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 > > ---------------------------------------------------------------- > 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 Sun Microsystems Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC