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

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

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.          |