RE: Import/Include - a proposal

On second thoughts this isn't such a big deal.

I think we need to check that the cdl schema complies with infoset rules
(which it probably does) 
and that we should add a sentence saying that the doc fragment to be
included must follow the rules 
defined by the infoset spec (an example is no relative namespaces).

Martin.

>-----Original Message-----
>From: public-ws-chor-request@w3.org 
>[mailto:public-ws-chor-request@w3.org] On Behalf Of Martin Chapman
>Sent: 16 September 2004 00:51
>To: 'Nickolas Kavantzas'; 'Steve Ross-Talbot'
>Cc: 'Monica J. Martin'; public-ws-chor@w3.org
>Subject: RE: Import/Include - a proposal
>
>
>
>Unless I have missed a mail in this thread, there is a MAJOR 
>issue here.
>
>
>Xinclude merges infosets but CDL has not defined (and I think will not
>define) an Infoset model.
>
>Steve's original proposal of the 13 July says
>
>	I propose that we use it [Xinclude]
>	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.
>
>However the resulting text that needs to be incorporated only 
>talks about Xinclude, and there is no new mechanism defined.
>
>
>Surely to close this resolution properly we need to define the 
>mechanism similar to Xinclude but for cdl documents which are 
>not infoset based.
>
>Martin.
>
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>[mailto:public-ws-chor-request@w3.org] On Behalf Of Nickolas Kavantzas
>>Sent: 15 September 2004 17:50
>>To: Steve Ross-Talbot
>>Cc: Monica J. Martin; public-ws-chor@w3.org
>>Subject: Re: Import/Include - a proposal
>>
>>
>>
>>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-001
>>> >> 5/
>>> >> 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 Thursday, 16 September 2004 23:41:26 UTC