Issues for Specification Management AB sub-committee

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 10870: schema.omg.org/spec/XMI/2.1
Issue 10918: Policy for URIs -- DI
Issue 10920: XMI files -- obscure acronyms
Issue 15138: New SMSC Issue on non-resolving hrefs in fUML XMI files

Issue 10870: schema.omg.org/spec/XMI/2.1 (smsc)

Please take a look at document omg/02-03-02 at http://www.omg.org/docs/omg/02-03-02.pdf.

According to it this directory (schema.omg.org/spec/XMI/2.1) should exist and that is where all schema, xmi, xml, idl etc. files relevant to XMI 2.1 should be available. It is reasonable to use this URI as the namespace name for XMI 2.1, although that might change a bit since we have decided to decouple the namespace name from the document specification version number in order to not require changing versions of schemas and namespaces if nothing changes in them from one version of the specification to another. But for now it will suffice, and we do need to do a round of minor update to omg/02-03-02 to reflect the rules for naming namespaces.

So the bottom line is, the fact that directory does not exist is not SBVR's problem. It is SMSC and OMG's problem.

Meanwhile, we should perhaps take the trouble to create all the directories corresponding to the currently existing formal specifications and start populating them.

I (and hopefully Pete with me) plan to start policing all new specifications that come by the AB to make sure that the namespace and schema URIs are consistent with omg/02-03-02.

We should consider a policy for this - there are already some pretty
obscure acronyms in the list for those not in the know.
For those working with/implementing the spec 'DI' is the phrase we
always use - including with customers

We should consider a policy for this - there are already some pretty
obscure acronyms in the list for those not in the know.
For those working with/implementing the spec 'DI' is the phrase we
always use - including with customers.

This is an Issue for the SMSC to resolve


Before final publication of fUML the following issue needs to be resolved
in some manner.


In the fUML FTF report there are normative xmi files,
( ptc/10-03-08.zip ), which include hrefs to primitive UML types.


However, these hrefs to not resolve to an actual file on the OMG server.


For example


           <ownedAttribute xmi:type="uml:Property"
             xmi:id="Syntax-CommonBehaviors-BasicBehaviors-OpaqueBehavior-body"
name="body"
             visibility="public" isOrdered="true" isUnique="false">
             <type xmi:type="uml:PrimitiveType"
               href="http://www.omg.org/spec/UML/20090901/uml.xml#String"/>
             <upperValue xmi:type="uml:LiteralUnlimitedNatural"
               xmi:id="Syntax-CommonBehaviors-BasicBehaviors-OpaqueBehavior-body-_upperValue"
               value="*"/>
             <lowerValue xmi:type="uml:LiteralInteger"
               xmi:id="Syntax-CommonBehaviors-BasicBehaviors-OpaqueBehavior-body-_lowerValue"/>
           </ownedAttribute>



where is the  link destination 
http://www.omg.org/spec/UML/20090901/uml.xml  ?    It does not resolve. 
Is this an OMG problem?


Partial explanation from Ed Seideitz



The URI http://www.omg.org/spec/UML/20090901 is the normative URI for
the UML 2.3 namespace (per the policy for URIs that you wrote, I think!
   ). Unfortunately, there does not really seem to be any complete
normative specification of the form of hrefs to standard elements like
http://www.omg.org/spec/UML/20090901/uml.xml#String. We are trying to
fix this in UML 2.4. However, hrefs using the file "uml.xml" have been
pretty common so far.