[NEW ISSUE] Need to define Namespace handling for included Composites

(Issue brought forward from OSOA)

Line numbers all refer to the 1.0 SCA
specifications published on www.osoa.org

RAISER:  Mike Edwards

DESCRIPTION:  

Current definition of SCA <include.../> for Composites
has two sets of problems associated with it: 

   1. It does not respect XML namespace usage - which forces
consistent namespace usage across including / included composites, which
in practice hinders re-use 

   2. It moves artifact resolution to the includer - which
does not relate well to the Domain resolution mechanism described in the
Assembly specification 

An updated definition of <include../> is required to address these
issues. 

More detail:

sca:include has creates two classes of problems:

a) it does not respect XML namespace usage

so that namespace prefices have to be used consistently and repeatedly
along

an assembly hierarchy which is unreasonable and hinders re-use.

b) it move artefact resolution to the includer

so that in particular the domain include mechanism cannot be expressed
in

sca:include. 

Raw proposal:

-------------

sca:include should be defined as include on the assembly graph, so that
artefact

namespaces and artefact resolutions stays local to the includee.

Example for a):

---------------

<?xml version="1.0" encoding="UTF-8"?> 

<composite 

        name="includer"

        xmlns="http://www.osoa.org/xmlns/sca/1.0"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xmlns:second="http://acme.org/stuff"

> 

        <include name="second:includee"/>

        

</composite> 

where 

<?xml version="1.0" encoding="UTF-8"?> 

<sca:composite 

        name="includee"

        targetNamespace="http://acme.org/stuff"

        xmlns:scabpel="http://www.osoa.org/xmlns/sca/bpel/0.9"

        xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0

../schemas/sca-core.xsd "> 

        

<sca:component name="xyz"> 

                <scabpel:implementation.bpel
process="myprocess"/> 

        </sca:component>

        

</sca:composite > 

Breaks. For two reasons:

1. the sca: prefix wouldn't have meaning in the "includer" composite.

2. worse: the scabpel: prefix wouldn't have a meaning. 

The latter is more significant. While this could be fixed for bpel, any
other

extension would lead to the same problem. 

It seems that textual include implies that namespaces have to be consistently

repreated all over the assembly hierarchy. E.g. suppose "Includee"
would look

like this:

<?xml version="1.0" encoding="UTF-8"?> 

<sca:composite 

        name="includee"

        targetNamespace="http://acme.org/stuff"

        xmlns:scabpel="http://www.osoa.org/xmlns/sca/bpel/0.9"

        xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:third="http://acme.org/stuff/third"

        xmlns:fourth="http://acme.org/stuff/fourth"

xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0

../schemas/sca-core.xsd "> 

        

<sca:component name="xyz"> 

                <sca:implementation.composite
name="third:acomposite"/> 

        </sca:component>

        

<sca:component name="xyz"> 

                <sca:implementation.composite
name="fourth:acomposite"/> 

        </sca:component>

</sca:composite > 

That would require to repeat "third" and "fourth" consistently
in the "includer"

PROPOSAL: None

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU