| Summary: | Support for UML 2.4.1 | ||
|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Kenn Hussey <Kenn.Hussey> |
| Component: | Core | Assignee: | Kenn Hussey <Kenn.Hussey> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ed, nicolas.f.rouquette |
| Version: | 3.2.0 | Keywords: | plan |
| Target Milestone: | M4 | Flags: | Kenn.Hussey:
juno+
|
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | Compliance | ||
|
Description
Kenn Hussey
FYI: Hi Nicolas, will do as soon as the TC meeting dust settles....I added it to my issues queue -Juergen At 01:35 PM 9/28/2011, you wrote: Juergen, Can you please assign a UML issue number to this? Ed suggested filing a separate issue for the XMI of the SysML 1.3 we published last week: http://www.omg.org/cgi-bin/doc?ptc/2011-08-11 I leave it up to the SysML RTF chairs to decide whether we need to file an issue for the missing Package::URIs in the published XMI for SysML 1.3 or handle this as an editorial/publication fix. Andrew made it clear though that we should treat anything that has an OMG document number as "written once & immutable thereafter". Therefore, we will need, at minimum, to publish the SysML 1.3 XMI artifacts under new document numbers. Since the SysML 1.3 inventory & spec document refer to the XMI artifacts by document number, we will need to republish these as well. Thanks Tomas for checking the details of the vendor-specific XMI issue I filed at NoMagic about profile-nested packages! Without your diligence, I would have missed the subtle flaws in the current XMI serialization process for applied profiles! - Nicolas. Begin forwarded message: From: "Rouquette, Nicolas F (313K)" < nicolas.f.rouquette@jpl.nasa.gov> Date: September 28, 2011 10:25:31 AM PDT To: "issues@omg.org" <issues@omg.org> Cc: " uml-spec-simplification@omg.org" < uml-spec-simplification@omg.org>, Tomas Juknevicius <tomasjkn@nomagic.com>, "uml-rtf@omg.org" <uml-rtf@omg.org> Subject: Clarifying the serialization of the application of Stereotypes defined in a Package nested in a Profile. This is an issue for UML 2.4.1. In 18.3.7, the semantics for Profile incompletely describes how to "Use XMI to exhange Profiles" for the case where a "Stereotype may be contained in a Profile or Package which defines the namespace for the Stereotype." (18.3.9, Stereotype Semantics). The Semantics section in 18.3.7 is missing the important constraints explaining some of the principles for the XMI serialization of the application of a Profile. The following constraints are consistent with the semantics of Stereotype Package containment specified in 18.3.9. 1) The XMI serialization of the application of a Stereotype is an XML Element tag of the form: "<[XML namespace prefix of the Package containing the applied Stereotype]:[applied Stereotype name]>" This is illustrated in the HomeExample profile in Fig. 18.8 whose Package URI, " http://HomeExample/20101201/HomeExample.xmi", is associated to the XML namespace prefix "HomeExample". Therefore, the application of the Stereotype HomeExample::Home serializes into an XML Element tag of the form: "<HomeExample:Home>" as shown in the example. The spec is missing an example where a Stereotype is contained in a Package that is nested in a Profile. SysML 1.3 can provide ample material for such an example. 2) An XMI serializer must include in an XMI document all the XML namespace prefix declarations corresponding to all the container Packages of all Stereotypes whose application to an Element is serialized in that XMI document. In some cases, this means that the XML namespace prefix used for a particular Package may be different than the convention used for OMG normative profiles (See UML 2.4.1, 18.3.7) where the nsPrefix is the name of the Profile. 3) The owning Package of each Stereotype must have a Package::URI specified so that an XMI processor can: - generate an XML namespace prefix for that Package when one of its contained Stereotypes is applied - resolve a reference to an applied Stereotype to the Package containing the definition of the Stereotype via the XML namespace prefix used for the containing Package URI. This can be specified in OCL2.3 as follows: context Stereotype inv StereotypeContainerPackageMustHaveURI: self.owningPackage.URI->notEmpty() 4) All the Stereotype-containing Packages in a Profile regardless of nesting must have distinct Package URIs. This can be specified in OCL2.3 as follows: context Profile inv StereotypeContainingPackagesMustHaveDistinctURIs: let pkgs : Set(Package) = self->closure(nestedPackage)->including(self) in let allURIs : Bag(String) = pkgs.URI in let uniqueURIs : Set(String) = allURIs->asSet() in allURIs->size() = uniqueURIs->size() 5) The OMG normative profile convention in 18.3.7 must be updated to provide a sensible nsPrefix for the XML namespace corresponding to a nested Package in a Profile. The conventions in 18.3.7 was written at a time when UML 2.0 allowed Stereotypes to be directly contained in a Profile. The conventions need to be updated to provide a sensible rule for generating the nsPrefix for a Package nested in a Profile. I suggest using the "."-concatenated sequence of names of the UML Namespaces from the Profile to the nested Package. For example, the SysML 1.3 Profile is named "SysML" and it defines a nested package "SysML::Blocks". The suggested nsPrefix for the UML Package SysML::Blocks would be "SysML.Blocks". This name is legal per the normative criteria for XML namespace prefix names (see: http://www.w3.org/TR/REC-xml/#NT-Name) - Nicolas. Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Thanks for the heads up, Nicolas. Is UML 2.4.1 not closed already? UML 2.4.1 has been released; it can be found at http://www.omg.org/spec/UML/2.4.1/ and all of the machine-readable files are at http://www.omg.org/spec/UML/20110701/. Support for UML 2.4.1 has been implemented and the migration guide at http://wiki.eclipse.org/MDT/UML2/UML2_4.0_Migration_Guide has been updated accordingly. The changes are available the integration build that was posted today. |