Issue 5959: XMI should be used for schema generation (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: This is a new issue for the Deployment FTF: Instead of introducing a new set of rules, the existing rules for XMI 2.0 Schema Production should be used. Proposed resolution: In section 6.1, "Introduction", change the last paragraph to read, The M1 mapping is realized using the UML Profile for CORBA, the M2 mapping is realized using the XML Metadata Interchange (XMI) Version 2 specification, chaper 2, "XML Schema Production." In section 6.5, "PIM for CCM to PSM for CCM for XML Transformation", change the first paragraph to read This section defines transformation T3 (as described in the introduction). It transforms the PIM for CCM into a PSM for CCM for XML that can be used to generate a concrete XML schema using the mapping rules described in chapter 2, "XML Schema Production" of the XML Metadata Interchange (XMI) Version 2 specification. Change the Generic Transformation Rules to read Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate XML schema for persistent storage of metadata. Management model elements, annotated with the «Manager» or «Exception» stereotype, are not part of the PSM for CCM for XML, they are mapped to IDL only. All classes in the PSM for CCM for XML are annotated with the "org.omg.xmi.contentType" tag set to the value "complex". All attributes are annotated with the "org.omg.xmi.element" tag set to "true". All packages are annotated with the "org.omg.xmi.nsURI" tag set to "http://www.omg.org/DnC" and the "org.omg.xmi.nsPrefix" tag set to the value "DnC". In the Special Transformation Rules section, in the description for the Any type, delete the Note that reads "Investigate whether the Any type that is part of XMI is sufficient." In the Others subsection of the Special Transformation Rules, add the following paragraph: The location attribute of the ImplementationArtifactDescription class and the idlFile attribute of the ComponentInterfaceDescription class contain URIs pointing to a file. URIs that consist of a relative path (using the rel_path branch in the URI BNF) are interpreted relative to the directory that the current document is in. URIs that consist of an absolute path (using the abs_path branch in the URI BNF) are interpreted relative to the current package. Change the Transformation Exceptions and Extensions section to read Metadata for a component package is usually spread out across several XML files, which we call descriptors. Certain associations are expected to be expressed by links within the same document, others are expected to link across documents. XMI takes care of both patterns by way of "proxies," which do not contain nested elements but a link attribute (either "href" or "xlink:href") referencing the target element by URI. A schema produced using the XMI rules for schema production allows proxies to appear anywhere. Composition associations in the model express that the class at the composite end owns and contains the class at the part end. In an XML file, the element that defines the class at the part end usually directly contains the definition for the class at the composite end. Since the default multiplicity on the near end of a composite association is one to one, the contained item cannot be legally contained in another element. It is possible to store it by itself in a separate file, though. For non-composite associations between classes with a common owner (composite end of composition), the definition of the class at the source end of the association must contain a proxy linking to the element at the target end of the association. The definition of the class at the source end cannot contain the definition of the element at the target end, because it is owned by the common owner, and its identity cannot be duplicated. Non-composite associations between classes that do not have a common owner are usually expressed by the element definining the class at the source end containing a proxy that links to an external document. Direct containment is possible but may result in duplicated data. While tools can decide to either combine information into a single XML document or to place information into arbitrary files, using XMI proxies to link to that information, it is expected that some model elements usually appear as the outermost document element of a standalone XML file. These commonly used descriptors are assigned descriptive terms and standard file extensions. - A Component Package Descriptor contains a ComponentPackageDescription document element; it has the ".cpd" file extension. - A Component Implementation Descriptor contains a ComponentImplementationDescription document element; it has the ".cid" file extension. - An Implementation Artifact Descriptor contains an ImplementationArtifactDescription document element; it has the ".iad" file extension. - A Component Interface Descriptor contains a ComponentInterfaceDescription document element; it has the ".ccd" (CORBA Component Descriptor) file extension. - A Domain Descriptor contains a Domain document element; it has the ".cdd" (Component Domain Descriptor) file extension. - A Deployment Plan Descriptor contains a DeploymentPlan document element; it has the ".cdp" (Component Deployment Plan) file extension. - A Toplevel Package Descriptor contains a ToplevelPackageDescription document element; it has the "package.pcd" file name. - Package files use the ".cpk" extension. Spreading information across files according to these patterns allow better reuse, for example by extracting an implementation from a package. Proxies follow the linking semantics specified by XMI. If a URI reference does not contain a fragment identifier (the "#id_value" part), then the target of the reference is the outermost document element of an descriptor file. If the link attribute of a ComponentPackageDescription proxy that is part of a SubcomponentInstantiationDescription element does not contain a fragment identifier, then the referenced file can be either a Component Package Descriptor or a package (i.e. a ZIP file with the ".cpk" extension containing the package). If a proxy's URIs consists of a relative path (using the rel_path branch in the URI BNF), then it is interpreted relative to the directory that the current document is in. URIs that consist of an absolute path (using the abs_path branch in the URI BNF) are interpreted relative to the current package. If a proxy's URI reference is a relative path, then the referenced file is looked for in the same directory as the document that contains the referencing element. If the URI reference is an absolute path, then the referenced file is looked for in the same package as the document that contains the referencing element. For backward compatibility, if the target of a proxy link does not exist, it will also be looked for under a top level "meta-inf" directory. Change the Mapping to XML section to read After applying the transformations defined in this section, an XML Schema is generated by applying the rules set forth in the XML Metadata Interchange specifcation, chapter 2, "XML Schema Production." Delete section 6.6, "Mapping Discussion." Delete chapter 7, "Mapping to XML Schema." Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: XMI should be used for schema generation  Date: Thu, 19 Jun 2003 10:11:39 -0400 Thread-Topic: XMI should be used for schema generation Thread-Index: AcM2bLOifs6gBjcsRwWnD47suNB9+Q== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JEBAkM002792 This is a new issue for the Deployment FTF: Instead of introducing a new set of rules, the existing rules for XMI 2.0 Schema Production should be used. Proposed resolution: In section 6.1, "Introduction", change the last paragraph to read, The M1 mapping is realized using the UML Profile for CORBA, the M2 mapping is realized using the XML Metadata Interchange (XMI) Version 2 specification, chaper 2, "XML Schema Production." In section 6.5, "PIM for CCM to PSM for CCM for XML Transformation", change the first paragraph to read This section defines transformation T3 (as described in the introduction). It transforms the PIM for CCM into a PSM for CCM for XML that can be used to generate a concrete XML schema using the mapping rules described in chapter 2, "XML Schema Production" of the XML Metadata Interchange (XMI) Version 2 specification. Change the Generic Transformation Rules to read Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate XML schema for persistent storage of metadata. Management model elements, annotated with the «Manager» or «Exception» stereotype, are not part of the PSM for CCM for XML, they are mapped to IDL only. All classes in the PSM for CCM for XML are annotated with the "org.omg.xmi.contentType" tag set to the value "complex". All attributes are annotated with the "org.omg.xmi.element" tag set to "true". All packages are annotated with the "org.omg.xmi.nsURI" tag set to "http://www.omg.org/DnC" and the "org.omg.xmi.nsPrefix" tag set to the value "DnC". In the Special Transformation Rules section, in the description for the Any type, delete the Note that reads "Investigate whether the Any type that is part of XMI is sufficient." In the Others subsection of the Special Transformation Rules, add the following paragraph: The location attribute of the ImplementationArtifactDescription class and the idlFile attribute of the ComponentInterfaceDescription class contain URIs pointing to a file. URIs that consist of a relative path (using the rel_path branch in the URI BNF) are interpreted relative to the directory that the current document is in. URIs that consist of an absolute path (using the abs_path branch in the URI BNF) are interpreted relative to the current package. Change the Transformation Exceptions and Extensions section to read Metadata for a component package is usually spread out across several XML files, which we call descriptors. Certain associations are expected to be expressed by links within the same document, others are expected to link across documents. XMI takes care of both patterns by way of "proxies," which do not contain nested elements but a link attribute (either "href" or "xlink:href") referencing the target element by URI. A schema produced using the XMI rules for schema production allows proxies to appear anywhere. Composition associations in the model express that the class at the composite end owns and contains the class at the part end. In an XML file, the element that defines the class at the part end usually directly contains the definition for the class at the composite end. Since the default multiplicity on the near end of a composite association is one to one, the contained item cannot be legally contained in another element. It is possible to store it by itself in a separate file, though. For non-composite associations between classes with a common owner (composite end of composition), the definition of the class at the source end of the association must contain a proxy linking to the element at the target end of the association. The definition of the class at the source end cannot contain the definition of the element at the target end, because it is owned by the common owner, and its identity cannot be duplicated. Non-composite associations between classes that do not have a common owner are usually expressed by the element definining the class at the source end containing a proxy that links to an external document. Direct containment is possible but may result in duplicated data. While tools can decide to either combine information into a single XML document or to place information into arbitrary files, using XMI proxies to link to that information, it is expected that some model elements usually appear as the outermost document element of a standalone XML file. These commonly used descriptors are assigned descriptive terms and standard file extensions. - A Component Package Descriptor contains a ComponentPackageDescription document element; it has the ".cpd" file extension. - A Component Implementation Descriptor contains a ComponentImplementationDescription document element; it has the ".cid" file extension. - An Implementation Artifact Descriptor contains an ImplementationArtifactDescription document element; it has the ".iad" file extension. - A Component Interface Descriptor contains a ComponentInterfaceDescription document element; it has the ".ccd" (CORBA Component Descriptor) file extension. - A Domain Descriptor contains a Domain document element; it has the ".cdd" (Component Domain Descriptor) file extension. - A Deployment Plan Descriptor contains a DeploymentPlan document element; it has the ".cdp" (Component Deployment Plan) file extension. - A Toplevel Package Descriptor contains a ToplevelPackageDescription document element; it has the "package.pcd" file name. - Package files use the ".cpk" extension. Spreading information across files according to these patterns allow better reuse, for example by extracting an implementation from a package. Proxies follow the linking semantics specified by XMI. If a URI reference does not contain a fragment identifier (the "#id_value" part), then the target of the reference is the outermost document element of an descriptor file. If the link attribute of a ComponentPackageDescription proxy that is part of a SubcomponentInstantiationDescription element does not contain a fragment identifier, then the referenced file can be either a Component Package Descriptor or a package (i.e. a ZIP file with the ".cpk" extension containing the package). If a proxy's URIs consists of a relative path (using the rel_path branch in the URI BNF), then it is interpreted relative to the directory that the current document is in. URIs that consist of an absolute path (using the abs_path branch in the URI BNF) are interpreted relative to the current package. If a proxy's URI reference is a relative path, then the referenced file is looked for in the same directory as the document that contains the referencing element. If the URI reference is an absolute path, then the referenced file is looked for in the same package as the document that contains the referencing element. For backward compatibility, if the target of a proxy link does not exist, it will also be looked for under a top level "meta-inf" directory. Change the Mapping to XML section to read After applying the transformations defined in this section, an XML Schema is generated by applying the rules set forth in the XML Metadata Interchange specifcation, chapter 2, "XML Schema Production." Delete section 6.6, "Mapping Discussion." Delete chapter 7, "Mapping to XML Schema." Subject: Updated proposed resolution for issue 5959 Date: Wed, 30 Jul 2003 14:58:46 -0400 Thread-Topic: issue 5959 -- Deployment FTF issue Thread-Index: AcM7XfU6AvHu1qdGEdeMjQCgyTbmFwbbBE4g From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6UItFkM025709 I spent some time today looking into URI terminology to clarify the idea that absolute file names within a package are resolved relative to the package, and not the file system that the package was extracted to. The intention is that a package cannot reference your private files. However, translating that intention into proper terminology does not seem easy. I've come up with this paragraph: When resolving relative references that appear in an XML document that is part of a Component Package, absolute paths are interpreted relative to that package. In particular, absolute-path references, i.e. URI references that begin with a single slash character, are interpreted within the current package, not relative to the file system that contains the package. It's not perfect, but reasonably accurate, I hope. Comments? Here's the full updated proposed resolution. It clarifies that only one XML schema is generated and changes the namespace prefix from "DnC" to "Deployment". The "relative references" explanation has been moved into a separate section, instead of giving it twice (once for the location and idlFile attributes, once for proxies). In section 9.1, "Introduction", change the last paragraph to read, The M1 mapping is realized using the UML Profile for CORBA, the M2 mapping is realized using the XML Metadata Interchange (XMI) Version 2 specification, chaper 2, "XML Schema Production." In section 9.5, "PIM for CCM to PSM for CCM for XML Transformation", change the first paragraph to read This section defines transformation T3 (as described in the introduction). It transforms the PIM for CCM into a PSM for CCM for XML that can be used to generate a concrete XML schema using the mapping rules described in chapter 2, "XML Schema Production" of the XML Metadata Interchange (XMI) Version 2 specification. Change the Generic Transformation Rules to read Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate an XML schema for persistent storage of metadata. Management model elements, annotated with the «Manager» or «Exception» stereotype, are not part of the PSM for CCM for XML, they are mapped to IDL only. All classes in the PSM for CCM for XML are annotated with the "org.omg.xmi.contentType" tag set to the value "complex", and the "org.omg.xmi.element" tag set to "true". All packages are annotated with the "org.omg.xmi.nsURI" tag set to "http://www.omg.org/Deployment" and the "org.omg.xmi.nsPrefix" tag set to the value "Deployment". In the Special Transformation Rules section, in the description for the Any type, delete the Note that reads "Investigate whether the Any type that is part of XMI is sufficient." Change the Transformation Exceptions and Extensions section to read Metadata for a component package is usually spread out across several XML files, which we call descriptors. Certain associations are expected to be expressed by links within the same document, others are expected to link across documents. XMI takes care of both patterns by way of "proxies," which do not contain nested elements but a link attribute (either "href" or "xlink:href") referencing the target element by URI. A schema produced using the XMI rules for schema production allows proxies to appear anywhere. Composition associations in the model express that the class at the composite end owns and contains the class at the part end. In an XML file, the element that defines the class at the part end usually directly contains the definition for the class at the composite end. Since the default multiplicity on the near end of a composite association is one to one, the contained item cannot be legally contained in another element. It is possible to store it by itself in a separate file, though. For non-composite associations between classes with a common owner (composite end of composition), the definition of the class at the source end of the association must contain a proxy linking to the element at the target end of the association. The definition of the class at the source end cannot contain the definition of the element at the target end, because it is owned by the common owner, and its identity cannot be duplicated. Non-composite associations between classes that do not have a common owner are usually expressed by the element definining the class at the source end containing a proxy that links to an external document. Direct containment is possible but may result in duplicated data. While tools can decide to either combine information into a single XML document or to place information into arbitrary files, using XMI proxies to link to that information, it is expected that some model elements usually appear as the outermost document element of a standalone XML file. These commonly used descriptors are assigned descriptive terms and standard file extensions. - A Component Package Descriptor contains a ComponentPackageDescription document element; it has the ".cpd" file extension. - A Component Implementation Descriptor contains a ComponentImplementationDescription document element; it has the ".cid" file extension. - An Implementation Artifact Descriptor contains an ImplementationArtifactDescription document element; it has the ".iad" file extension. - A Component Interface Descriptor contains a ComponentInterfaceDescription document element; it has the ".ccd" (CORBA Component Descriptor) file extension. - A Domain Descriptor contains a Domain document element; it has the ".cdd" (Component Domain Descriptor) file extension. - A Deployment Plan Descriptor contains a DeploymentPlan document element; it has the ".cdp" (Component Deployment Plan) file extension. - A Toplevel Package Descriptor contains a ToplevelPackageDescription document element; it has the "package.pcd" file name. - Package files use the ".cpk" extension. Spreading information across files according to these patterns allow better reuse, for example by extracting an implementation from a package. Proxies follow the linking semantics specified by XMI. If a URI reference does not contain a fragment identifier (the "#id_value" part), then the target of the reference is the outermost document element of an descriptor file. If the link attribute of a ComponentPackageDescription proxy that is part of a SubcomponentInstantiationDescription element does not contain a fragment identifier, then the referenced file can be either a Component Package Descriptor or a package (i.e. a ZIP file with the ".cpk" extension containing the package). Insert a new section "Interpretation of Relative References" that reads Interpretation of Relative References URI references are used by proxies and appear in the location attribute of the ImplementationArtifactDescription class and the idlFile attribute of the ComponentInterfaceDescription class. When resolving relative references that appear in an XML document that is part of a Component Package, absolute paths are interpreted relative to that package. In particular, absolute-path references, i.e. URI references that begin with a single slash character, are interpreted within the current package, not relative to the file system that contains the package. Change the Mapping to XML section to read After applying the transformations defined in this section, an XML schema is generated by applying the rules set forth in the XML Metadata Interchange specifcation, chapter 2, "XML Schema Production." Delete section 9.6, "Mapping Discussion." Delete chapter 10, "Mapping to XML Schema." Update appendix B, "XML Schema for CCM," with the contents of the file ftp://ftp.omg.org/pub/deployment_ftf/Deployment.xsd Subject: RE: Updated proposed resolution for issue 5959 Date: Wed, 30 Jul 2003 15:29:45 -0400 Thread-Topic: Updated proposed resolution for issue 5959 Thread-Index: AcNWzwUARdyek8KqEdeMjQCgyTbmFwAAGPyg From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6UJQBkM026136 > > > > When resolving relative references that appear in an XML document > > that is part of a Component Package, absolute paths are interpreted > > relative to that package. In particular, absolute-path references, > > i.e. URI references that begin with a single slash character, are > > interpreted within the current package, not relative to the file > > system that contains the package. > > > > I think that you should keep the definition of interpretation of URI as is > defined by RFC 2396. I don't want to implement a URI interpreter that is > separate from everything else. If you look through the RFC, there is a > detailed explanation of how to convert a relative URI to a absolute URI. > IMHO, we shouldn't add to the confusion. Also not everybody will extract a > package onto a filesystem. > I fully agree, and IMHO none of the above conflicts with RFC 2396. The trick is that the application needs to introduce a Base URI with the required properties into the relative-URI resolution process However, there is no way to specify this Base URI, as the semantics of the file: scheme are too imprecise (there doesn't seem to be a good definition for the interpretation of file: URIs), as you mention the package might not be in a file system anyway, and you don't want to invent a new scheme for our purposes. So the above text is meant to express that in the resulting URI, after resolving a relative URI against the application-defined Base URI, the abs_path component of the URI is interpreted relative to the package. I tried composing text that talked about application-specific Base URIs, but in the end I felt that it was getting out of hand. So I ended up with the first sentence of the above paragraph, and supplied it with another sentence that describes the net effect. Suggestions welcome. Frank Subject: RE: Updated proposed resolution for issue 5959 Date: Mon, 4 Aug 2003 09:06:09 -0400 Thread-Topic: Updated proposed resolution for issue 5959 Thread-Index: AcNYdjeepTDZ78RHEdeMjQCgyTbmFwCEQDzQ From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h74D2GkM003700 > > I don't know if I am completely misunderstanding your position. But then I > am here to make sure that I understand it. So please let me know if I got > it wrong. > I think the first thing to understand is the rationale. Imagine a component package is extracted into a file system, and the top-level document was accessed using the URI file://localhost/path/to/package/package.pcd Then any URI within the package could be for example an absolute-path URI such as /windows/passwords.txt. According to RFC 2396, this relative URI, with the above base URI, would resolve to the new URI file://localhost/windows/passwords.txt The rationale is to disallow this behavior. It should be impossible to "leave" the package using relative URIs. Consequently, a package should be treated as the root of a file system, so that the relative URI /windows/passwords.txt would be resolved to file://localhost/path/to/package/windows/passwords.txt The problem is to phrase text that has the above effect without violating the standard rules for resolving relative URIs. Or maybe I'm trying too hard, and this "feature" is unnecessary? Frank Subject: RE: Updated proposed resolution for issue 5959 (2) Date: Fri, 8 Aug 2003 09:41:40 -0400 Thread-Topic: Updated proposed resolution for issue 5959 (2) Thread-Index: AcNdKEhVxbKJ0ckGEdeMjQCgyTbmFwAhvvJw From: "Pilhofer, Frank" To: "Krishnakumar B" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h78DfskG013131 > > This interpretation has some loopholes which might lead to non- > standard interpretation/implementations of URI resolution. > What part of the text are you concerned about? > > > XML documents that are part of a Component Package can use > > relative-path references (i.e. URIs that do not begin with > > a scheme name or a slash character) to reference documents > > and other artifacts within the same package. > This piece of the text says that implementations MUST handle relative- path references correctly, so that packages can depend on that fact. > > If you want to disallow moving out of the package, you can say that > URI references within a Component Package should only be relative > URIs. This would satisfy the goal of making a Component Package a > standalone entity. > That doesn't work. Relative references could embed many leading ".." path segments that would ultimately resolve to the root directory for file: base URIs. Note that the updated text avoids specifying this goal by declaring all relative URIs that point outside the package as implementation- specific. Also, be careful about your terminology. "Relative URI" is a term that encompasses relative-path references (which is what you're talking about here), absolute-path references (e.g. "/hello/world") and network-path references (e.g. "//server/file/name"). > > The interpretation of relative URI references does not preclude > specification of implementation specific URIs i.e custom schemes. > Right. We could just go ahead and define a new scheme so that "ComponentPackage:///" referred to the package's root directory. However, that is (a) overkill, (b) silly, and (b) some implemen- tations may decide that accessing the rest of the filesystem using relative URIs has value. > > > file://localhost/windows/passwords.txt > > Now the important thing is that only because localhost was portion > of the authority component of the base URI, you were able to access > /windows/passwords.txt using a relative URI. If the authority > component is different, then one would not be able to circumvent > that using relative URIs. > Right again, we could equally well define a "ComponentPackage" authority, so that "file://ComponentPackage/" would reference the package's root. But (a) the same reasoning as above applies, and (b) file URIs don't have any well-defined semantics to start with. > > The interpretation of absolute URI references within a Component > Package and interpretation of schemes used in such references, are > implementation specific. This specification encourages usage of > relative URI references within a Component Package for maximum > interoperability with deployment tools developed by different > vendors. > Isn't that just about the same as what I said? Except that your text allows absolute-path references (as part of relative URIs) without assigning any semantics to them. (Since a component packager could not depend on the choice of the "root" directory.) > > I can raise a separate issue, but I don't know the procedure > involved. > Easy. Just send a mail to issues@omg.org once the resolution is adopted (no point in complaining officially about text that's not part of the spec yet). Frank Date: Fri, 17 Oct 2003 17:07:21 -0400 From: Kevin Richardson Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en To: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin > > Andreas Hoffmann > > unhofer.de> cc: > Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT > 10/02/2003 10:07 AM > > > > Hi FTF members, > > this is the first voting for the OMG Deployment FTF. For details on the > issue resolutions please refer to the attached document listing all the > issue resolutions of this voting. Compared to Tuesday's draft version I > have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" > to "Duplicate or merged". Anyway, this classification has no impact on the > voting. > > In order to give all FTF members enough time to study the issue resolutions > and their impacts on the specification the voting deadline is Monday 20th > October, 2003, 20:00 GMT. > > ------------------- snip -------------------- > > ** Deployment FTF Voting Poll 1 ** > ** Voting Deadline October 20, 2003, 20:00 GMT ** > > Company: > > Voter: > > Regards > Andreas > > ==================================================================== > Andreas Hoffmann > Fraunhofer FOKUS - Research Institute for Open Communication Systems > Kaiserin-Augusta-Allee 31 > D - 10589 Berlin Date: Sat, 18 Oct 2003 09:04:12 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: Kevin Richardson CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Kevin, Similar to the email to Dave, since Frank isn't around, I'll try to clarify some of the issues that you didn't want to accept. In general, to make progress, when comments come up at the ballot that were not raised earlier during the email and telecon discussions, it might be more efficient to raise them as new issues - especially in the case where they are making minor improvements to the larger proposed resolutions. Your call of course. Kevin Richardson wrote: One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case The core difference was between a reference to an implementation vs. a reference to an interface, which were considered to be distinct enough to warrant different classes. OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? The persistence is certainly not normative. Perhaps such a clarification should be a separate issue? The core issue of using the standard XMI->XML Schema mapping was mandated by the Architecture Board. 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? Me too:-) Perhaps a separate issue to clarify these few sentences? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. This new operation description was carefully written to mirror the wording for the installPackage operation, which, now that I look at it, could benefit from your comments in the same way. Perhaps a new issue that applied your comments to both? OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. The changes were all to change "String" to "String[0..1]" for the attributes already specified in the text as "optional". OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. These good refinements should be submitted as a new issue if this passes... OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities 6042 was a spelling error. Do you mean a different issue? OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) ------------------------------------------------------------------------ Name: omg-deployment-ftf-01_10_03.zip omg-deployment-ftf-01_10_03.zip Type: application/zip Encoding: base64 Download Status: Not downloaded with message Subject: RE: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Date: Sat, 18 Oct 2003 21:54:09 -0400 Thread-Topic: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Thread-Index: AcOU8uaB9jNtCmcaRd+EFxP2so3RqwA7g5PQ From: "Pilhofer, Frank" To: "Kevin Richardson" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9J1nY2U028067 Hi Kevin, thanks for the work you spent on this. Here are some comments. > > OMG Issue No: 5957: No - in InstanceDeploymentDescrition, > PlanConnectionDescription, PlanPropertyMapping, PackageError there are > still references to the label attribute. > The resolution should also contain explicit instructions to update the > figures. (if these are incorporated - Yes) > You're right, the "label" attribute still occurs in a few places where it shouldn't. I can find it in 6.4.9.1 (AssemblyConnectionDescription) and 6.8.3.1 (MonolithicDeploymentDescription) and in the diagram for 6.11.1. I cannot find the other occurences you mention. The diagram needs to be updated. for the other two occurences, the offending text should be deleted (by a separate issue, if this resolution is adopted). > OMG Issue No: 5959: No - I've got a couple of discussion > items before > I say yes, 1) In the GenericTransformationRules it states the "an XML > schema for persistent storage of metadata" - is it the case that the > metadata has to be persistently maintained? Well, in the usual CORBA sense, anything on disk - like an XML file - is persistent, as files persist across server restarts. No persistency in the sense "it needs to be kept around for any amount of time" is implied, but maybe this needs better wording. > 2) The paragraph beginning with "Composition associations in the > model..." confuses me to no end, am I just missing something? This section elaborates the potential spreading of XML data across multiple files - it is possible, but not mandatory, to store information in multiple rather than a single file. When the model uses a composite association, e.g. a Node containing Resources, then these Resources are owned by the Node, and it is inappropriate to share information about the Resource, as the Node is its sole parent. In an XML document, information about the Resource will always be directly embedded within the Node's information, e.g. www.omg.org .... Because of the XMI rules, however, the Resource information may be placed in a different file, and the Node can then use an http: XLink to link to the Resource data. Maybe the text needs some fine-tuning, but I don't think this should deter us from accepting the resolution, which makes a worthwile change overall. Frank Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 20 Oct 2003 09:45:46 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 10/20/2003 09:44:34 AM OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not clear why another class is needed. Changing the meaning of depends on. It seems like there is different dependencies types, loading, execution, uses. This needs further thought with use cases and use case realizations to show justification. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes, but diagrams need to be updated too OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes., chapter misspelled in 1st change OMG Issue No: 5960: Yes. OMG Issue No: 5961: no, what is the relationships between this and the install operation. What is the outcome of a createpackage? OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - It appears the changes are being made to agree with the corresponding text. I don't think the text is correct. These attributes should not be optional. OMG Issue No: 5964: NO, Which issue change has precedence 5957? No mention of updating corresponding diagrams. Without updated diagrams with text changes it is unclear why all these changes are necessary and how all these changes fit together. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: Yes if this valid for XML and transformation rules. solution for this issue. OMG Issue No: 6024: Yes, provided the XML is valid syntax. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fa