The approach I used to build a construct similar to the following:
<SurveyTeam>
<Member>
<Person/>
<Role/>
</Member>
</SurveyTeam>
has been termed a "fat protocol" in some XML discussion groups. Another
approach makes heavy use of Attributes with minimal nesting of Elements
and has been termed a "thin protocol".
The advantages of using thin is that it can produce a more compact data
structure. The advantages of using fat are increased data modularity and
exandability. Change can be localized to a small area of a deeply nested
structure. Fat XML protocol increases a data modeler's ability to add
new constructswhile minimizing impact to other modules of the data
structure. This is keyto high quality modular development.
I'm am a strong believer in iterative development using a spiral
development methodology. Explicit specifications early in the
development cycle only serve to limit my options. I'm not clairvoyant
and I get a serious chuckle when anyone purports to be.
The goal is to specify early versions of Cave Survey Data in XML with a
fat protocol until a stable data model has been accomplished (end of
first spiral). Following this a new requirements development process
will lead to methods of putting the fat protocol on a diet, to creater a
thinner protocol. The end product should be a complete data model, well
scoped, and efficently designed.
DSK
Paul & Eleanor wrote:
> I'm just playing with this particular XML and attempting to simplify.
> It may not be possible.
>
> Richard Knapp wrote:
>
>>> Another point:
>>>
>>> Why not just put person inside instrument? After all you allow no
>>> more than a person per instrument. Or do you see a complex and
>>> non-one-to-one relationship between person, role and instrument?
>>
>> Not true. It is within the problem domain to allow for trade-offs at positions.
>
>
> How is that helped by Devin's format, hurt by having Person within
> Instrument?
>
> A new set of people would certainly have to occur. I guess in one case,
> the new
> Survey Team block would reassign roles, while a person in instrument
> would require
> an extra level of tags.
>
> <Survey>
> ...
> <SurveyTeam>
> <Member>
> <Name>Paul Hill</Name>
> <Role>Survey Grand Master</Role>
> </Member>
> </SurveyTeam>
> ...
> </Survey>
>
> vs.
>
> <Survey>
> ...
> <Instrument>
> <Compass>
> <Person>Paul Hill</Person>
> </Compass>
> </Instrument>
> ...
> </Survey>
>
> Looks to me like the need to reassign roles could be supported by either
> position
> of <Person>.
>
> I notice that Role at this time is just PCDATA, so possible values are
> anything.
> I certainly would take this further and make sure fixed values include
> the name of each
> possible instrument, plus at least "Book" or "Sketcher" or something.
>
> I guess I say it another way. What does the whole:
>
> <SurveyTeam>
> <Member>
> <Person/>
> <Role/>
> </Member>
> </SurveyTeam>
> and
> <Instrument>
> ....
> </Instrument>
>
> really do? It seems like <SurveyTeam> and <Member> don't provide much
> (except for the usual
> place to add new future elements) that would not be similarly
> accomplished with fewer tags by simply
> having a <Person> within <Instrument>.
>
> If there is a desire to allow room for extended tags, elements could
> always be added inside
> of <Person>.
>
> As I suggested, I'm just playing with the various tags by asking if they
> are necessary.
>
> -Paul
>
>
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST