Re: Import/Include - a proposal

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 Tuesday, 13 July 2004 12:47:22 UTC