From Omar Wiki

This page is a placeholder for questions, issues and suggestions involving the ebXML Registry profile for Web Services.

Issues Applicable to all / most Profile

• Need to specify a discovery mechanism for knowing what profiles are supported by a registr
• Need to specify generic guidelines for generating deterministic ids
• How to handle ids that are too long
• Need to specify generic rules for delete of metadata when cataloged object is deleted
• Need to specify generic rules for update of metadata when cataloged object is updated

Specific Issues

• Spec change: need to associate the ExtrinsicObjects, that represent the WSDL files, with the Service object that implmenents them. Add an Association with type urn:oasis:names:tc:ebxml-regrep:AssociationType:HasWSDL.

• Spec question: what should be the convention of providing an id for the EO? For example: <target namespace>:

• Spec change: catalog schemaLocation not just importedNameSpaces?

• Spec change: importing wsdl:types from XSD file. The wsdl:types element MAY contain child <xsd:schema> definitions of its types. Alternatively, wsdl:types MAY contain <xsd:schema><xsd:import> child elements. Each <xsd:import schemaLocation="<URL type>" /> element is handled depending on the schemaLocation attribute's URL type.
  • Relative URL type. If the URL is relative, user MUST submit dependent xml schema files in zip file (perhaps jar file, in future). Each <xsd:import schemaLocation="types.xsd" /> MUST be mapped to a rim:ExtrinsicObject. This EO object MUST be associated with the EO that contains the <wsdl:types> using a rim:Association object with type urn:oasis:names:tc:ebxml-regrep:AssociationType:Imports.
  • Absolute URL type. If the URL is absolute, each <xsd:import schemaLocation="http://myhost.com/types.xsd" /> MUST be mapped to a rim:ExternalLink. This EL object MUST be associated with the EO that contains the <wsdl:types> element using a rim:Assocation with type urn:oasis:names:tc:ebxml-regrep:AssociationType:Imports.
• Concerns about how registry will handle existing wsdl-related metadata and content
  • If a user submits a wsdl file that imports a wsdl file contained in the same zip/jar file, AND that wsdl file already exists in the repository, how should the registry behave? Here are some alternatives:
    • Create a new rim:ExtrinsicObject for bundled wsdl file. Store bundled wsdl file as new content in the Repository.
    • Version the existing rim:ExtrinsicObject. Replace the existing wsdl file in the Repository with bundled one.
    • Version the existing rim:ExtrinsicObject. Store bundled wsdl file as new content in the Repository.
    • Use existing rim:ExtrinsicObject. Replace the existing wsdl file in the Repository with bundled one.
    • Use existing rim:ExtrinsicObject. Do not replace the existing wsdl file in the Repository. Throw exception describing duplicate content.
    • Use existing rim:ExtrinsicObject. Do not replace the existing wsdl file in the Repository.
    • Conditionally version the rim:ExtrinsicObject (and add wsdl file as new content to Repository) depending on the value of some of the metadata. If the value does not indicate to version, use existing rim:ExtrinsicObject and wsdl content.
  • Suggestion: use the value of the <definitions targetNamespace="..." /> attribute. If it contains a new version number, version the existing rim:ExtrinsicObject with the new attribute value. Add wsdl file as new content to Repository. Create new rim:Association between versioned EO and new content.
  • Example:
    • wsdl file1 is submitted with <definitions targetNamespace="urn:oasis:names:tc:ebxml-regrep:wsdl:registry:bindings:3.0" />. Registry creates new rim:ExtrinsicObject with id="urn:oasis:names:tc:ebxml-regrep:wsdl:registry:bindings:3.1". Rest of processing is as described in this section.
    • User submits second wsdl file with exactly the same targetNamespace value. Registry ignores this wsdl file, and uses existing rim:ExtrisicObject and wsdl content in Repository.
    • User submits third wsdl file with targetNamespace="urn:oasis:names:tc:ebxml-regrep:wsdl:registry:bindings:3.1". The new version number indicates to the Registry to version the existing rim:ExtrinsicObject with id urn:oasis:names:tc:ebxml-regrep:wsdl:registry:bindings:3.1, and to add the wsdl file to the Repository. If this approach is acceptable, need to update spec on how users indicate they want to version existing wsdl content.