Re: Import/Include - a proposal

Hi All,

	Allow me to suggest that using xinclude is definitely the proper 
approach. To be honest, there is no way of preventing this - xinclude was 
designed to be used ex post facto without any intervention even from the 
author. However, it seems we are adding 3 new requirements, as noted by 
Monica: a) CDL processor must support xinclude b) CDL processor must 
include xbase support c)CDL processor must be able to identify incorrect 
syntactic *and* semantic construction *after* transclusion of all 
referenced external entities. Item c) proposes some strict constraints on 
the construction of the PVIS. We should make sure these issues are 
addressed. Note that use of xinclude *does* implicitly require support for 
xbase.

	It may be worthwhile to investigate the possibility of only allowing 
transclusion in CDL documents when enclosed in specific elements, which 
could then be defined as having a content model of ANY as described in the 
xml schema spec. This would reduce a certain number of foreseeable errors, 
and also allow import of documents (and fragments) from other namespaces 
in a well-defined way.

	Importing documents from multiple namespaces should not pose any great 
problem, so long as the schema is well constructed.

Regards,

D-



On Tue, 13 Jul 2004 17:46:57 +0100, Steve Ross-Talbot 
<steve@enigmatec.net> 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.
>>
>>
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Daniel Austin, Chief Product Engineer
Sun NetConnect
303 272 9733    daniel.b.austin@sun.com

"When I get a little money, I buy books. If there is anything left over, I 
buy clothing and food. "
- Erasmus

Received on Tuesday, 13 July 2004 14:01:40 UTC