Hi,
Just one brief reply for consideration:
This similar pattern design already exists in XSD schema language.
===========================
<appinfo
source = anyURI>
Content: ({any})*
</appinfo>
===========================
[3.13.2 XML Representation of Annotation Schema Components]
One can consider both the child content and URI attribute value of
<service-ref> together as one unit of open content.
In the WSDL 1.1 or 2.0, (implicit) extensible attributes are allowed
everywhere.
IMHO, the option (B) proposal text already has said much more on how to
handle and interpret the URI attribute and the child content, compared
with XSD and WSDL.
(Of course, you may say "XML Schema sucks". ;-) )
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
Please see
below
Alex Yiu wrote:
Option (B) : Make the "reference-scheme" attribute of of "service-ref"
element optional:
The “bpws:service-ref” has an optional attribute called
“reference-scheme” to to denote the URI of the reference interpretation
scheme of service endpoint, which is the child element of
bpws:service-ref.
What is a reference interpretation scheme? I've never heard of such a
term. I did a Google search and all that came up was your original
posting on the issue.
Both the child element and optional
"reference" URI constitutes the open content of "service-ref".
The semantics is just like other open-content model (e.g XML Schema).
An open content model as used in the context of XML means the ability
to insert new elements into an XML instance without having to change
the schema. Schemas that use an open content model have well defined
rules for how to ignore the additional elements. XML Schema does not
have an open content model. This has caused enormous problems and is an
issue I recently addressed on my blog -
<http://www.goland.org/Tech/xmlschemabackwardscompat.htm>.
What you are proposing, as near as I can understand it, seems unrelated
to the concepts of an open content model.
Could you please define exactly what you mean by open content in this
context?
The URI of reference scheme and the namespace
URI of the child element of bpws:service-ref are not necessarily the
same. Typically, this optional attribute is used ONLY when the child
element of the “bpws:service-ref” is ambiguous by itself. The optional
attribute supplies further information to disambiguate the usage of the
content.
Can you supply evidence that in the vast majority of cases a single URI
will be sufficient to provide the disambiguation you request here? Can
you supply evidence that in the vast majority of cases such
disambiguation is even necessary?
Example: different treatments of wsdl:service
element
* If that attribute is not specified, use the namespace URI of the
content element within the wrapper to determine the reference
scheme of service endpoint.
* if the attribute is specified, use the URI as the reference
scheme
of service endpoint and treat the content element within the
wrapper accordingly.
o When the "reference-scheme" attribute is specified, the URI
value is MOST LIKELY different from the namespace URI of
the
content element for EPR.
Essentially what the reference-scheme ends up meaning is "Whatever the
semantics are that are associated with the root element of the EPR
override them in some undefined way with this single URL."
Given that the BPEL spec cannot say anything useful about what the
semantics of the URL are and how it relates to the EPR I don't see any
compelling reason to include the attribute in our EPR description. The
attribute is just magic, it has no semantics on its own other than
somehow, in a completely undefined way, redefining the EPR's meaning.
The whole point of agreeing to make EPRs opaque was to keep the magic
out of BPEL. We just say 'EPRs go here' and no more. This attribute
violates that agreement. Either EPRs are opaque or they are not. I
believe they should be opaque and I believe that requires removing the
attribute.
* When the BPEL container fails to
interpret the combination of the
"reference-scheme" attribute and the content element OR just the
content element alone, a standard fault
"bpws:UnsupportedReference" must be thrown.
Even this requirement cannot be fully supported. After all, given the
completely undefined semantics of the attribute it is certainly
possible that the attribute by itself may provide enough information
that a BPEL engine could process the rest of the EPR without
understanding the EPR's elements elements. For example, the URL could
have an EPR embedded inside of it. That is the kind of magic the
attribute opens up and this is the kind of magic I think we shouldn't
have in BPEL.
I'm sorry Alex but your proposal uses terms I either don't recognize or
don't understand in this context and involves semantics that range
between unproven (as in is disambiguation necessary and if so is one
attribute enough?) to undefined (the exact relationship between the
attribute and the EPR).
I look forward to reading your clarification on the meaning of the
terms used above that I didn't recognize. Perhaps that will provide me
with the understanding I need to support your proposal. But for now I
move that we remove the reference-scheme attribute from BPEL all
together.
Thanks,
Yaron
|