## caGrid restrictions on use of caDSR types:

-   Cyclic package dependencies are not allowed.

    -   e.g. Package A cannot contain a Class with an association to
        Class B, if Class B's containing Package contains a Class with
        an association to Package A

        -   Nor can this be true through transitivity

-   Data exposed (classes and attributes) must be used under a
    consistent project version

    -   That is, even though Classes and Attributes can be versioned
        individually, in order to use those types on the grid, they need
        to be packaged together in a consistent project version.

-   Data services can only expose a (non-proper) subset of a single
    project

    -   one can always create a new project to aggregate existing
        projects

## XML Schema Existence Rules:

-   *We don't currently require attribute sharing, as a CDE is an
    attribute bound to a Class... we enforce at the Class-level, and the
    class is required to handle the structure of its attributes (e.g.
    what to call them, whether to use xml attributes or elements, etc)*

```{=html}
<!-- -->
```
-   Each caDSR data object (as part of a specific Project version) used
    in the grid must have its XML format modeled in an XML Schema that
    is registered in the GME. It is expected to be able to be
    represented as an XML document (a self-standing element). That is,
    the object must be able to be passed around the grid (as result of a
    query to a data service, or invocation of an analytical service, as
    well as act as input to a operation).

-   Every caDSR Package (as part of a specific Project version) must
    have a corresponding XML Schema that is registered in the GME, even
    if it just imports a series of other XML Schemas and doesn't define
    any of its own types.

-   Every caDSR Project must have a corresponding XML Schema registered
    in the GME. It will most likely just imports a series of other XML
    Schemas (corresponding to its Packages' schemas), though it may
    define its own types.

-   These rules let the XSD modeler create any level of schema
    granularity from 1 per project, down to 1 per Class, but there is
    always a defined way to retrieve all of the types for a given
    Project, Package, and Class.

-   We need a default heuristic for assigning namespaces (can use what
    we had in 0.5), but user's should be able to specify a non-default
    mapping.

## caDSR to XML Schema Mapping Rules:

-   Project -\> Namespace

-   Package -\> Namespace

-   Class -\> SchemaTypeReference (must define a global element, should
    also define a type)

    -   This is a one-to-one mapping, right? For a given
        Project/Package, a CDE can only map to a single
        SchemaTypeReference. However, a CDE can be shared between
        Projects/Packages and have different Schemas, right?

        -   Right, a given Class should have one representation in the
            grid (one XSD definition). However, a CDE may be represented
            multiple ways, as defined by the containing Class it is used
            in.

-   Attribute -\> SchemaTypeReference (+ XPath or XPointer?)

    -   *If we require that the attribute exist as either an attribute
        of the Class's Element or as a direct sub-Element, we don't need
        a complex description like XPath or XPointer, we can just have a
        structure to represent "name" and "type (attribute, sub element,
        or element's text)". We will also have to allow for the text of
        an element (elements that extend string or some other xs type)
        to be modeled as an attribute of a class because the caDSR does
        not allow for the extension of basic types. For example, an
        element that extends xs:string and has attributes would likely
        be modeled in the caDSR as a class with a value* *attribute in
        addition to its other attributes.*

        -   *Will this always be the case for existing XSD though?*
            *It's certainly possible to not be. And in the trivial
            cases, the expression would be simple anyway, so might as
            well use the more expressive language.*

-   Association -\> SchemaTypeReference (+ XPath or XPointer?)

    -   We don't currently specify how Class associations should be
        modeled. This isn't necessarily a critical issue because as long
        as the source Class adheres to the specifications, it is
        responsible for managing access to the target Class. That is, if
        the source Class is transported over the grid, it is expected to
        manage the serialization/deserialization of its associated
        Classes.

        -   It is an application specific decision to control the extent
            to which (if any) associations are populated in transported
            Classes. For example, the current behavior of data services
            is that each Class instance (Object) returned, is only has
            its attributes populated and no associated objects. However,
            the input to the query operation is (will be) itself a caDSR
            registered class (CQLQuery -- name may change), that does
            have associated objects populated as it is transported over
            the grid.

        -   However, for applications or middleware working directly at
            the XML layer (such as the workflow infrastructure,
            distributed query infrastructure, or any generic grid
            client), the representation of associations may be
            important. For example, if Class A has two *different* named
            associations to Class B, it may be important to know how to
            extract, from an XML representation of Class A, a particular
            Class B instance from one of the associations. In this case,
            there needs to be a well-defined way to go from the logical
            model of the associations in caDSR, to how it is represented
            in the corresponding XML Schema definition for Class A.

        -   There are 3 main approaches to representing Class
            associations I have seen:

            1.  Create a sub-element in the source Class's corresponding
                Element that shares the name of the target role name.
                Nest the instances of the target Class as their
                corresponding Elements. *I consider this the preferred
                approach.*

> \<A\>
>
> \<bCollection\>
>
> \<B someAttributeOfB="foo"/\>
>
> \<B someAttributeOfB="foo"/\>
>
> \</bCollection\>
>
> \</A\>

2.  Nest the instances of the target Class as their corresponding
    Elements directly under the corresponding element of the source
    Class, ignoring the rolename. *Basically doesn't work for multiple
    named associations to the same class.*

> \<A\>
>
> \<B someAttributeOfB="foo"/\>
>
> \<B someAttributeOfB="foo"/\>
>
> \</A\>

3.  Nest sub-elements, that share the name of the target role name, in
    the source Class's corresponding Element. These elements are of the
    "type" of the target Classes corresponding type. *Requires not only
    global element defections for each Class, but also global type
    definitions. Also generally not what the modeler intended (multiple
    occurrences of the association name). Also problematic for
    extracting associated instances and using them on their own. This is
    what the caCORE SDK 3.1 generated XSDs look like.*

> \<A\>
>
> \< bCollection someAttributeOfB="foo"/\>
>
> \< bCollection someAttributeOfB="foo"/\>
>
> \</A\>

-   It seems the best approach is to share a common model for pointing
    to both attributes and associated classes. This should probably be
    an (restricted) XPath relative to the containing Class's
    representation. For the examples above this would be:

    1.  /bCollection/B

    2.  /B

    3.  /bCollection

```{=html}
<!-- -->
```
-   Model designers may wish to provide an arbitrary amount of
    indirection between associated classes in the schema. For example, a
    schema defines /A/B/C/D and I only want to expose A-\>D in my model.
    However, it seems this can be handled fine by the XPath strategy.

It may be necessary to map XML Schema types to caDSR CDEs. For example,
inspect WSDL from a service to determine if it exposes some CDE. This is
certainly a one-to-one mapping and should be trivial to implement a
reverse-lookup.

### Resources discussing UML to XSD Mapping:

### [**[http://www.xml.com/lpt/a/2001/08/22/uml.html]{.mark}**](http://www.xml.com/lpt/a/2001/08/22/uml.html)

-   [[http://www.xml.com/lpt/a/2001/09/19/uml.html]{.mark}](http://www.xml.com/lpt/a/2001/09/19/uml.html)

-   [[http://www.xml.com/lpt/a/2001/10/10/uml.html]{.mark}](http://www.xml.com/lpt/a/2001/10/10/uml.html)

-   [[http://www.sparxsystems.com.au/resources/xml_schema_generation.html]{.mark}](http://www.sparxsystems.com.au/resources/xml_schema_generation.html)

**SchemaTypeReference** (represents a global type in a given schema)

-   Schema's Namespace

-   Type (element, complexType, simpleType)

-   Name (of the Type)

## 0.5 Approach:

The caGrid 0.5 Technical Guide has a detailed explanation of the
approach in Chapter 4.

It is essentially a rule based approach to naming XML schema namespaces
from information in caDSR:

gme://\<Classification Scheme\>.\<Context Name\>/\<Classification Scheme
Version\>/\<Classification Scheme Item\>

Or in other words:

gme://\<Project Short Name\>.\<Context Name\>/\<Project
Version\>/\<Package Name\>

### Uniqueness assumed (versions aside):

-   context name

-   project short name in context

-   package name in project

-   class name in package

-   attribute name in class

### Issues:

-   (critical) The naming assumptions above are not correct (the names
    used are allowed to be edited).

-   (critical) Doesn't handle external standard schemas (e.g. MAGE-ML)