W3C home > Mailing lists > Public > public-ws-chor@w3.org > September 2004

Re: Import/Include - a proposal

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Wed, 15 Sep 2004 09:50:19 -0700
Message-ID: <414872CB.F89B50AE@oracle.com>
To: Steve Ross-Talbot <steve@enigmatec.net>
CC: "Monica J. Martin" <Monica.Martin@Sun.COM>, public-ws-chor@w3.org

This is the current edited text from Greg based on Yves instructions. Are you confortable with it?

2.4.6.2 Including Choreographies
Choreographies or fragments of Choreographies can be reused in any Choreography definition by using XInclude [ref to Xinclude 1.0].
This mechanism allow the merge of several XML infosets into one that
becomes the Choreography definition.

A CDL processor MUST resolve all XInclude declaration in the Choreography
definition before doing any CDL-related processing.

Example:

<choreography name="newChoreo" root="true">
...
   <variable name="newVariable" informationType="someType"
             role="randomRome"/>
   <xi:include href="genericVariableDefinitions.xml" />
   <xi:include href="otherChoreography.xml"
               xpointer="xpointer(//choreography/variable[1]) />
...
</choreography>


Steve Ross-Talbot wrote:

> On 13 Jul 2004, at 17:33, Monica J. Martin wrote:
>
> >
> >> SRT: Import/Include in WS-CDL
> >>
> >> Proposal:
> >> Given that the XInclude mechanism [ref] has been created for the
> >> express purpose of providing a generic mechanism for recognizing and
> >> processing inclusions in XML grammars I propose that we use it as the
> >> basis for our own importation mechanism in WS-CDL. This mechanism
> >> would be a syntactic inclusion identical to XInclude and would
> >> conform to the processing model of XInclude. Parsing and validation
> >> of a merged info-set (the result of XInclusion) would then be a
> >> separate and orthogonal process.
> >>
> >> This would allow us to close the following issues:
> >> Issue 469 - because it does a merge on info-sets and the correctness
> >> of the result is WS-CDL's problem.
> >
> > mm1: Should then WS-CDL address this problem then a separate issue?
>
> Correct - Should just be a validation against schema problem. The
> simple approach is to fail in all cases when validation fails rather
> than attempt to add semantics to fix it.
>
> >
> >> Issue 484 - because XInclude doesn't care I would suggest neither
> >> should we.
> >
> > mm1: If we include at multiple levels of the choreography, do we raise
> > any compatibility issues with BPEL for example? BPEL only imports at
> > the process level. Does this have any affect on the validity of the
> > choreography description? I agree this may be a separate,
> > non-syntactic issue.
> >
>
> If the document or fragment being imported is correct it situ then no
> problems occur. If of course it is incorrect it would be no different
> to importing some random C into an existing C file using #include.
>
> >> Issue 485 - doesn't overide at all and in cases with clashes it could
> >> be a schema error.
> >
> > mm1: From reading the xinclude note, it appears that the namespace of
> > the included item is retained.  I agree that could result in a schema
> > error, and therefore could be recognized by WS-CDL in validation
> > correct?
> >
>
> Sounds like one to discuss so we are all clear on it.
>
> >> Issue 561 - see 485 above
> >
> > mm1: Agreed - see comments above.
> >
> >> Issue 609 - not so sure on this one but my sense is that it is
> >> irrelevant to a syntactic inclusion mechanism and so can be closed
> >
> > mm1: Therefore, we will not address any non-syntactic issues, correct?
> >
>
> That is my understanding (see simple approach above). XInclude just
> produces a valid infoset in situ but does nothing about the semantics
> of what is produced so it could be illegal WS-CDL.
>
> >> Issue 611: XInclude handles this (see processing model and uri
> >> resolution).
> >
> > mm1: We should recognize that xinclude requires the making the base
> > URI property required instead of optional. Perhaps this is a hint to
> > implementers or it may be implicit in our reference to the use of
> > xinclude.
> >
>
> Good point. Again one to discuss.
>
> >> For summary of above issues see
> >> (http://lists.w3.org/Archives/Public/public-ws-chor/2004Jul/att-0015/
> >> draft-import-mm2-062904.pdf)
> >
> >
> > mm1: It appears that you wish to close all issues to address syntactic
> > inclusion only. If that is indeed correct, I would propose, please,
> > that the specification indicate that WS-CDL only explicitly addresses
> > syntactic inclusion. Thanks.
> >
>
> If we go this route then I agree with you completely. Clarity is a rare
> gift.
>
> >> Excerpts below are taken from http://www.w3.org/TR/xinclude/
> >>
> >> 1.2 Relationship to XML External Entities
> >> ... XInclude operates on information sets and thus is orthogonal to
> >> parsing....
> >>
> >> 1.3 Relationship to DTDs
> >>
> >> XInclude defines no relationship to DTD validation. XInclude
> >> describes an infoset-to-infoset transformation and not a change in
> >> XML 1.0 parsing behavior. XInclude does not define a mechanism for
> >> DTD validation of the resulting infoset.
> >>
> >> 1.4 Relationship to XML Schemas
> >>
> >> XInclude defines no relationship to the augmented infosets produced
> >> by applying an XML schema. Such an augmented infoset can be supplied
> >> as the input infoset, or such augmentation might be applied to the
> >> infoset resulting from the inclusion.
> >>
> >> 1.5 Relationship to Grammar-Specific Inclusions
> >>
> >> Special-purpose inclusion mechanisms have been introduced into
> >> specific XML grammars. XInclude provides a generic mechanism for
> >> recognizing and processing inclusions, and as such can offer a
> >> simpler overall authoring experience, greater performance, and less
> >> code redundancy.
> >>
> >>
> >> 4 Processing Model
> >>
> >> Inclusion as defined in this document is a specific type of [XML
> >> Information Set] transformation.
> >>
> >> [Definition: The input for the inclusion transformation consists of a
> >> *source infoset*.] [Definition: The output, called the *result
> >> infoset*, is a new infoset which merges the source infoset with the
> >> infosets of resources identified by IRI references appearing in
> >> xi:include elements.] Thus a mechanism to resolve URIs and return the
> >> identified resources as infosets is assumed. Well-formed XML entities
> >> that do not have defined infosets (e.g. an external entity with
> >> multiple top-level elements) are outside the scope of this
> >> specification, either for use as a source infoset or the result
> >> infoset.
> >>
> >> xi:include elements in the source infoset serve as inclusion
> >> transformation instructions. [Definition: The information items
> >> located by the xi:include element are called the *top-level included
> >> items*]. [Definition: The top-level included items together with
> >> their attributes, namespaces, and descendants, are called the
> >> *included items*]. The result infoset is essentially a copy of the
> >> source infoset, with each xi:include element and its descendants
> >> replaced by its corresponding included items.
> >
> >
Received on Wednesday, 15 September 2004 16:51:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:05 GMT