Re: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-designposition paper.

[Dave Carlson <dcarlson@ontogenics.com>]

I've found it very helpful to use XSD group or attributeGroup to define
reusable content in an OO model, and these do not create any additional
containers in the XML instance.  If I use UML to define the schema model, I
assign <<XSDgroup>> or <<XSDattributeGroup>> stereotypes to the UML classes,
then my schema generator produces the corresponding constructs in the schema.

When I reverse engineer existing XSD into UML, any <group> or <attributeGroup>
definitions become appropriately stereotyped classes in the UML model.  With
this approach the UML model is much more readable as a conceptual model of the
vocabulary, but the XML instance is still flat.  Similarly, when this more
structured UML/OO model is used to generate relational database schema or Java
processors, the groups create a more componentized Java application without
requiring container elements in the XML instance.

Gunther, is this what you mean by "partial object classes"?

Regards,
  Dave Carlson

----- Original Message -----
From: "Stuhec, Gunther" <gunther.stuhec@sap.com>
>
> I guess that the instances itself do not need any containers, because it is
easier to define any interfaces for business objects.
>
> My suggestion is that we have partial object classes instead of unstructured
containers. This partial object classes makes the building of structure much
more controllable and the partial object classes are reausable, too.
>
> Otherwise, if we use "containers", than we need some simple rules for the
definition and processing in a automatic manner. One another import thing is,
that the names containers impacts the dictionary entry name. If you use a
container with the name "header", than the dictionary entry name will be
"order.header.id" instead of "order.id". This representation is not ebXML CCTS
compliant.
>