OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ubl-lcsc] RE: [ubl-ndrsc] UML diagrams for 0p70 cycle3


R10 in the naming and design rules document says:

[R 10]	The name of a complex type based on an object class must be the name
of the object class, with the separators removed and with the "Details"
suffix replaced with "Type" (example: The Party. Details object class
becomes the PartyType complex type).

So the schemas are wrong to use FooDetailsType as a complex type name -- it
should be FooType (another hard-won rule).  The reason for the consensus
around FooType was to distinguish it from a Foo element.  The SC was aware
the types and elements inhabit separate name spaces (not namespaces ;-)  but
the consensus was that the "Type" suffix would make things more
understandable for users.

Dave's rule 3 will be addressed in the LCSC call this morning.  So to
Gunther's point we will soon (hopefully) be almost implementing Dave's rule
1, and completely implementing Dave's rule 3.  (rule 2 is solely a UML
mapping rule so it has no bearing on our schemas).

-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com] 
Sent: Tuesday, January 21, 2003 5:04 AM
To: Dave Carlson; Tim McGrath
Cc: Kohsuke Kawaguchi; ubl-ndrsc@lists.oasis-open.org; norman.walsh@sun.com;
Jeff.Suttor@sun.com; gkholman@cranesoftwrights.com; Burcham, Bill;
adam@talaris.com; jon.bosak@sun.com
Subject: RE: [ubl-ndrsc] UML diagrams for 0p70 cycle3


Hello Dave and Tim,

we can implementing all three UML mapping rules into our XML schema
definition directly. Therefore, a mapping between the XML schema and UML is
not necessary. 
But this is with our current rules with global declared elements not
possible, now.

Kind regards,

	Gunther

-----Original Message-----
From: Dave Carlson [mailto:dcarlson@ontogenics.com] 
Sent: Montag, 20. Januar 2003 02:18
To: Tim McGrath
Cc: Kohsuke Kawaguchi; ubl-ndrsc@lists.oasis-open.org; norman.walsh@sun.com;
Jeff.Suttor@sun.com; gkholman@cranesoftwrights.com;
bill_burcham@stercomm.com; adam@talaris.com; jon.bosak@sun.com
Subject: [ubl-ndrsc] UML diagrams for 0p70 cycle3


Tim, et al,

See the attached zip file for UML class diagrams of all schemas in cycle 3
review package.  These are in GIF format.  The reverse engineering algorithm
applies 3 simple rules to obtain the class diagram, which comes very close
to illustrating the core component conceptual model from the spreadsheets.
My goal for these class diagrams is to facilitate review of the information
model implied by these schemas.  And also to facilitate QA of the schemas to
assure that they reflect the original content analysis.  The class diagrams
are derived only from the XSD source, nothing else.

The mapping rules to UML:

    1.  Remove the "DetailsType" suffix from complexType names.
    2.  For each complexType child element, if its type is either a
simpleType or a complexType with simpleContent, then map that child element
to a UML attribute.
    3.  For the resulting UML attribute name (derived from the child element
name), remove the prefixed class name (i.e., remove the qualified object
class term).  So, "ActualShipmentHandlingCode" is changed to "HandlingCode"
because it is an attribute of the UML class "ActualShipment".

The decomposition into sub-diagrams is based on my visual review of the
diagrams to keep them from becoming too complex and to minimize redundancy
across diagrams.

An additional simplification could be made by removing the representation
term from the attribute name suffix, because this representation term is
also clearly evident in the UML attribute type name (which is a core
component type, e.g. CodeType).

If I were a Java developer working with these schemas, the UML class
diagrams are close to what I would desire as a Java API.

Tim, I'll update document section listing these diagrams and send it to you.

Also,I don't have write access to the ubl-lcsc list, so would someone
forward?

Regards,
  Dave Carlson

----- Original Message -----
From: "Tim McGrath" <tmcgrath@portcomm.com.au>
To: "Kohsuke Kawaguchi" <kohsuke.kawaguchi@sun.com>
Cc: <jon.bosak@sun.com>; <adam@talaris.com>; <bill_burcham@stercomm.com>;
<gkholman@cranesoftwrights.com>; <Jeff.Suttor@sun.com>;
<norman.walsh@sun.com>; <ubl-lcsc@lists.oasis-open.org>;
<ubl-ndrsc@lists.oasis-open.org>
Sent: Friday, January 17, 2003 9:20 PM
Subject: [ubl-ndrsc] validation of UBL Schemas for release 0p70 - CYCLE 3


> My apologies for doing this, but we have now another update for the 
> Validation team.  This is CYCLE 3.
>
> This fixes the duplicate ID problem in the CoreComponentType.xsd  
> (only an 8k file, but I feel better resending the whole set again).
>
> PS
> Gunther, can you note the changes in this updated version, given your 
> ongoing discussions about this schema.
>
> --
> regards
> tim mcgrath
> fremantle  western australia 6160
> phone: +618 93352228  fax: +618 93352142
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC