Jeremy Boynes wrote:
Pete Robbins wrote:
Is the order of <entryPoint...>s, <component...>s, <externalReference..>s,
<wire...>s, <any> defined by the specification? If so then is moving the <
import.xxx> location the correct thing to do?


The order is defined (see the schema for exact details).

We modified the schema to add <import> anyway so I don't think moving it
further up adds any more problems.

It seems to me that knowing the types for any complex properties is needed
before parsing the files (.module, .fragment etc). Is the handling of
complex properties being discussed in the specifiactions group?


It is under discussion, yes. There is a proposal in for a recursive
composition model and as part of that some changes have been proposed
for how properties are defined and set. To my knowledge the inclusion of
SDO types or WSDL definitions has not yet been discussed.

Whether you need to define the types in advance depends on whether the
parser is able to hand imports during the parse process. I think
requiring the user to do it in advance add inconvenience that can be
avoided. XML-Schema and WDSL both allow imports/includes as part of
their definition and I think SCDL should be similarly self-contained.
This makes the parser a little more complex, but that is our problem not
the user's.

--
Jeremy

+1 for moving <wsdl.import> up, I think it makes more sense to an app developer to list his wsdls at the top of sca.module before using them later in the document. I can also think of other use cases where I'd like to reuse a number of wsdls in a jar for example and package in that jar an sca.fragment file with wsdl.imports for them. So I should be able to reference a wsdl imported in an x.fragment file from other fragments in the same module or sca.module itself.

If nobody objects, I can move the wsdl.import up in the XSD. I'm in the middle of changes to this project anyway.

--
Jean-Sebastien

Reply via email to