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

RE: Import/Include - a proposal

From: Martin Chapman <martin.chapman@oracle.com>
Date: Thu, 16 Sep 2004 00:51:10 +0100
To: "'Nickolas Kavantzas'" <nickolas.kavantzas@oracle.com>, "'Steve Ross-Talbot'" <steve@enigmatec.net>
Cc: "'Monica J. Martin'" <Monica.Martin@Sun.COM>, <public-ws-chor@w3.org>
Message-ID: <001901c49b7e$e0e0ccf0$2cae2382@ie.oracle.com>

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 Wednesday, 15 September 2004 23:52:13 GMT

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