EXPRESS-XML Issues
This thread copied over from the Groove Diagnostics Discussion area...
Tim
************************************************************************
****
Tim Wilmering 9/29/2005
Yes, each entity in the hierarchical element hierarchy can have multiple
parents or children as can be seen by the recursive relations:
members : SET OF hierarchical_element;
INVERSE
parents : SET OF hierarchical_element FOR members;
Note there are also constraints on the parent member relations to ensure
that the graph is acyclic and that the indenture level of the
parent-child hierarchies is consistent.
Tim
************************************************************************
*****
John Ralph 9/28/2005
Darryl makes a valid point. In fact, there are several relationships in
EXPRESS that are difficult (or at least non-obvious) to translate into
XML. I'm sure that a little more investigation is needed to accurately
do a 1-to-1 mapping.
To respond directly to Darryl's comment regarding hierarchicalElement:
I'm not sure I agree that EXPRESS defines each member as having multiple
possible parents. The spec (in 5.1.32) states that hierarchical_element
is an "...ABSTRACT SUPERTYPE OF (ONEOF(diagnosis, repair, ....)..." In
the attribute definitions, "parents" (the inverse) is defined as "The
set of elements that have the current element as a member." This seems
to imply the need for a key/keyref relationship in the XML, but further
investigation with the authors of EXPRESS might be enlightening.
************************************************************************
*****
Darryl Busch - 9/27/2005
Another issue is that the EXPRESS models contain a lot of relationships
that are not easily represented in vanilla w3c XML, and at least some
relationships were not translated properly. I have not carefully
compared the XML to the EXPRESS, but I was able to find a
mis-translation in the first place I suspected:
hierarchialElement: In EXPRESS it is a part-whole hierarchy (each
member can have multiple parents). In XML it became a tree hierarchy
(each member can have at most one parent).
Darryl
************************************************************************
******
Darryl Busch - 7/25/2005
I have some concerns about the way the EXPRESS models have been
translated to XML. In many cases, container layers in the model
hierarchy have been dropped because it makes the XML look simpler. I
believe this causes more problems than it is worth.
Here are two illustrative examples from the DCM that I will use to make
my point:
ENTITY session;
trace : LIST OF step;
caused_by : OPTIONAL SET [1:?] OF cause;
[snip]
END_ENTITY;
ENTITY step;
[snip]
reasoner_hypothesis : OPTIONAL SET OF inferred_diagnosis;
[snip]
diagnoses : SET [2:?] OF inferred_diagnosis;
[snip]
END_ENTITY;
In the XML schema, <session> contains a list of <step>s and a list of
<cause>s as direct children, without any intermediate container elements
called "trace" or "caused_by" respectively.
Ditto for step and its children.
Here are the problems I see:
1) This further breaks the 1-to-1 correspondance between the EXPRESS and
XML. The two specs get harder for us to maintain, and harder for users
to correlate.
2) The AI-ESTATE services in 6.1 have names that are based on the entity
& attribute names. E.g. there is an service called
"append_to_trace_list". Dropping the trace containter from the XML
confuses this relationship.
3) IMHO, having the containers in the XML simplifies binding. If I
were to implement DCM in OO software, I would create container classes
corresponding to trace, caused_by etc.
4) The container names can convey important meaning. In the example
above, "reasoner_hypothesis" conveys the true meaning better than
"inferred_diagnosis".
5) The container names can provide required model structure. The
EXPRESS attributes "reasoner_hypothesis" and "diagnoses" above are a
good example. They both contain sets of "inferred_diagnosis" but the
two sets have different meanings and should be kept separate. In the
XML, <inferredDiagnosis> is a direct child of <step> that appears in
only one set, so the distininction between the "reasoner_hypothesis" and
the "diagnoses" is lost.