RE: [provision] URN de-referencing in multi-point identifiers

["Darran Rolls" <Darran.Rolls@waveset.com>]

A correction is required to my last example below.

 

The shorthand form of:

 

          <superiorClasses>

               <objectClassDefinitionReference name="urn:oasis:names:tc:SPML:standard:person"/>

          </superiorClasses>

 

 

Would of course be:

 

          <superiorClasses>

               <objectClassDefinitionReference name="person">

                   

                    <spml:providerIdentifier providerIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

                         <spml:providerID>urn:oasis:names:tc:SPML</spml:providerID>

                    </spml:providerIdentifier>

 

                    <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

                         <schemaID> urn:oasis:names:tc:SPML:standard</schemaID>

                    </schemaIdentifier>

               <objectClassDefinitionReference/>

            </superiorClasses>

 

 

=========================================================

Darran Rolls                      http://www.waveset.com

Waveset Technologies Inc          drolls@waveset.com

512) 657 8360                    

=========================================================

 

-----Original Message-----
From: Darran Rolls
Sent: Tuesday, April 22, 2003 10:54 AM
To: provision@lists.oasis-open.org
Subject: [provision] URN de-referencing in multi-point identifiers

 

As discussed on yesterdays con-call, there is a possible need to change the way we use URN’s in the identifiers for extend requests and in schema-schema.  The issue is that for extended requests (providerID & operationID) and schema-schema referencing (providerID & schemaID) we *optionally* support URN for both parts of the identifier, making it nasty to de-reference a compound identifier.

 

In summary, the decision is this, do we restrict schemaID and operationID to be genricString (with suitable character restrictions) in order to allow us to make simple URN form references to extendedRequests and schema-schema object classes and attributes.  If we do we loose the ability to create neat hierarchies of schema/operation ID’s that make use of the URN model. 

 

The following explains this issue in detail using a schema-schema providerIdentifier/schemaIdentifier example.  Please review so that we can record a motion on Mondays call.  Right now, I’m personally for leaving it as it is and adding normative text to the extent of “if you use the shorthand URN model it must be parsable by the PSP else you have to user the long hand”  - thus we keep the “hierarchies” ability…

 

------ Details ----

 

First let’s look at an example that DOES NOT use a URN for both to make sure we’re all on the same page.  Taking the interop schema as an example, say we define the “standard” schema as a base service schema that defines an objectClassDefinition of “person” as shown below:

 

<schema xmlns="urn:oasis:names:tc:SPML:1:0:schema" xmlns:spml="urn:oasis:names:tc:SPML:1:0:core" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" majorVersion="1" minorVersion="0">

    

     <!—Here is the provider ID as a URN -->

     <spml:providerIdentifier providerIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

          <spml:providerID>urn:oasis:names:tc:SPML</spml:providerID>

     </spml:providerIdentifier>

    

     <!—Here is the schema ID as a generic String so everything is cool -->

     <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1.0:core#GenericString">

          <schemaID>standard</schemaID>

     </schemaIdentifier>

    

     <!—Here are my locally defined attributes -->

     <attributeDefinition name="cn" description="Full name, or common name."/>

     <attributeDefinition name="email" description="E-mail address."/>

     <attributeDefinition name="description" description="Description."/>

    

    <!—Here is my service object definition -->

     <objectClassDefinition name="person" description="Standard person.">

          <memberAttributes>

               <attributeDefinitionReference name="cn" required="true"/>

               <attributeDefinitionReference name="email" required="true"/>

               <attributeDefinitionReference name="description"/>

          </memberAttributes>

     </objectClassDefinition>

</schema>

 

So now I define a derivative of that service schema to define the service “interopPerson” as follows:

 

<schema xmlns="urn:oasis:names:tc:SPML:1:0:schema" xmlns:spml="urn:oasis:names:tc:SPML:1:0:core" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" majorVersion="1" minorVersion="0">

 

     <!—Here is the new provider ID as a URN -->

     <spml:providerIdentifier providerIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

          <spml:providerID>urn:oasis:names:tc:SPML</spml:providerID>

     </spml:providerIdentifier>

 

     <!—Here is the new schema ID as a generic String -->

     <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1.0:core#GenericString">

          <schemaID>interop</schemaID>

     </schemaIdentifier>

    

     <attributeDefinition name="memberLevel"/>

     <attributeDefinition name="company"/>

     <attributeDefinition name="registrationTime"/>

    

     <objectClassDefinition name="interopUser" description="Interoperability demo user.">

         

          <!—Here is the meat of it – note the reference uses the shorthand URN for to reference the -->

          <!—providerID “urn:oasis:names:tc:SPML” the schemaID “standard” and the objectClass -->

          <!—we are inheriting from “”person” -->

          <superiorClasses>

               <objectClassDefinitionReference name="urn:oasis:names:tc:SPML:standard:person"/>

          </superiorClasses>

          <memberAttributes>

               <attributeDefinitionReference attributeName="memberLevel"/>

               <attributeDefinitionReference attributeName="company"/>

               <attributeDefinitionReference attributeName="registrationTime"/>

          </memberAttributes>

     </objectClassDefinition>

</schema>

 

In the above example, the shorthand form only works because we can parse in from the genericStrings of the objectClass, schemaID  to the providerID (obviously no “:” chars are therefore allowed in the schemaID and objectClassDefinition either)…

 

The alternative is to make the superiorClass definition use a longhand reference to the providerID and schemaID as shown below:

 

          <superiorClasses>

               <objectClassDefinitionReference name="person">

                   

                    <!—So I have to explicity call out the providerID -->

                    <spml:providerIdentifier providerIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

                         <spml:providerID>urn:oasis:names:tc:SPML</spml:providerID>

                    </spml:providerIdentifier>

 

                        <!—And the same for the schemaID--> 

                    <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1.0:core#URN">

                         <schemaID> urn:oasis:names:tc:SPML:interop</schemaID>

                    </schemaIdentifier>

               <objectClassDefinitionReference/>

         

          </superiorClasses>

 

 

 

=========================================================

Darran Rolls                      http://www.waveset.com

Waveset Technologies Inc          drolls@waveset.com

512) 657 8360                    

=========================================================