Hi, Yaron,
You are reading my proposal not-so-correctly.
See my quick comment and clarification inline in GREEN:
Yaron Y. Goland wrote:
You identify
two goals for adding in namespace:
> (a) partition different extensions (from Dieter's proposal) (b) to
lookup the
> owner / definer of extension.
Regarding (a): As I explain in the Blog article there are good reasons
for wanting multiple namespaces in a single extension. Dieter's
proposal makes such behavior illegal. Your proposal makes such behavior
effectively illegal because you explicitly require people to draw
conclusions about the contents of an extension from a namespace
attribute and since only a single namespace can be specified it is
impossible to use elements from two namespaces.
My proposal allows one extension-URI defines extension multiple
namespace URIs.
However, I DO want to disallow that one namespace URI is defined by
multiple extension-URIs.
Because, I want to make sure there is ONE owner per namespace.
Regarding
(b): As I pointed out in the letter to Danny the XML namespace proposal
explicitly states that there is no requirement that namespaces be
dereferencable and yet your proposal is based on the assumption that
such de-referencing is possible.
NEITHER namespace-URI NOR extensionURI need to be
de-referenceable. The BPEL implementation just needs to recognize the
extensionURI. Similar situation in your proposal. Just look at what
happened in the JSP and XSD world. URI used in XSD:schema-location and
JSP:taglib-location do NOT need to be de-referenencable. Those URI just
needs to be known by the implementation. People misunderstood that they
must be de-referenceable, because de-referenceable
is the simplest usecase that people learn first.
To achieve
the goals you laid out I believe you need to adopt a variant of Yuzo's
proposal and include optional namespace declarations and allow for
multiple such declarations to be used. But I really think that is over
engineering. At this point just putting in an extensionURI is
sufficient.
Hmm ... you lost me here ... :-) ... I would say I would not go to the
direction of Yuzo's proposal in general.
> All
definitions of extension are now COMPLETELY opaque and "stored" inside
those
> 2 extensionURIs. Say, the BPEL editor that is being used
understands
> "http://foo2impl.com" but NOT "http://bar2impl.com". Can the
editor safely
> ignore <bar:ExtElem3> ? The answer is NO, unless the BPEL
edtiors understand all
> extensionURI used in this BPEL. Because, it even CANNOT identify
WHICH extension
> URI controls the meaning of <bar:ExtElem3 />.
If the implementation understand http://foo2impl.com then clearly it
must already know which elements are part of http://foo2impl.com and
therefore already knows if <bar:ExtElm3> is part of
http://foo2impl.com. If ExtElm3 is a part of http://foo2impl.com then
there is no issue, the engine knows what to do. If ExtElm3 is not part
of foo2impl.com then there is also no issue since the engine knows to
ignore it. Hence there is no issue.
"If ExtElm3 is not part of foo2impl.com then
there is also no issue since the engine knows to ignore it." ...
Why can the engine safely ignore it? The "must-understand" information
in Dieter's proposal is "moved" to the semantics represented by the
extensionURI in your proposal. "bar:ExtElem3" may be defined as
MUST-understand by "http://bar2impl.com". It's just a particular
implementation don't recognize it.
Bascially, my proposal is to make your proposal less opaque by
exposing relation between namespace-URI and MUST-understand (which is
factored out of Dieter's proposal).
Thanks!
Regards,
Alex Yiu
