[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC