>
> Mmm. There is the getQNameDefinition method on the Node interface which is
> supposed to help with that. The spec section says:
>
> * 4695 10.7.4 get QName Definition
> * 4696 In order to make sense of the domain-level composite (as
> returned by get Domain-Level Composite), it
> * 4697 needs to be possible to get the definitions for named artifacts
> in the included composites. This
> * 4698 functionality takes the supplied URI of an installed
> contribution (which provides the context), a supplied
> * 4699 qualified name of a definition to look up, and a supplied symbol
> space (as a QName, e.g.
> * 4700 wsdl:PortTypeportType). The result is a single definition, in
> whatever form is appropriate for that
> * 4701 definition type.
>
> I've not yet implemented getQNameDefinition but did intend to, using the
> above domain Composite i guess it would be something like the following to
> get at the helloworld Composite:
>
> getQNameDefinition("helloworld", new QName("http://sample";,
> "helloworld"), "composite")
>
> Or are you thinking of doing something else?
>
> ...ant
>
>
I think that's part of it, and that will help also when just browsing
to the leaf nodes of the contribution hierarchy. The other thing that
I had in mind was that it would be useful to be able to flatten the
domain composite so the user can see it all. But maybe that only works
in the browser view where it would be useful for the user to be able
to navigate the structural hierarchy of the domain composite. If we
tried to print this out as xml though you'd end out with things
like...
<component>
<implementation.composite>
<component>
etc.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
