Resend.
Daniel B. Austin wrote:
> 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.
>>>
>>>
>>>
>>
>
>
>
Forwarded message 1
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