wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsn] [Namespace URIs] Proposal to split the existing namespa ces
- From: Steve Graham <sggraham@us.ibm.com>
- To: "Patil, Sanjay" <sanjay.patil@sap.com>
- Date: Tue, 11 May 2004 17:25:54 -0400
Hi Sanjay:
I don't believe the consequences of
the decision are very great here. It is just a slight shift in URI
usage. In the original WSDL and XSD, for simplicity we chose to have
one namespace per spec. One less namespace URI to generate a xmlns:xxx
for. Nothing more. As it turns out, some tools actually had trouble
dealing with the fact that a xsd:schema within a wsdl:types element had
the same @targetNamespace as an xsd:schema in an xsd file.
With regards to "closely related"
namespaces. No tool (that I am aware) really takes advantage of that affinity.
Besides with the date-encoded namespace URIs suggested in my proposal,
the affinity should still be suggested based on the spec name and date
portions of the URI.
With regards to namespace resolvability,
many namespace URIs are in fact resolvable. XML Schema never forced
the resolvability property for reasons that are beyond my understanding.
I have talked to some XSD wizards and came away convinced that the
decision XSD designers made was to satisfy a corner case, and was not terribly
convincing.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
| "Patil, Sanjay" <sanjay.patil@sap.com>
05/11/2004 05:02 PM
|
To:
Steve Graham/Raleigh/IBM@IBMUS, wsn@lists.oasis-open.org
cc:
Subject:
RE: [wsn] [Namespace URIs] Proposal
to split the existing namespa ces |
I am not sure I understand fully
the consequences of the decision here.
I guess there were valid reasons
for using the same namespace for the related set of WSDL and XSD instances.
The simplest and perhaps most significant advantage of using the same namespace
IMHO was that - tools could easily recognize and build on the fact that
the WSDL, XSD (and perhaps some other artifacts in future) instances
tagged with the same namespace are closely related. For example, if one
of the artifacts changes, I could possibly use the knowledge of the relationship
to analyze the impact of the change.
With separate namespaces for the
WSDL and XSD, I suppose the relationships between them have to be captured
explicitly and the mechanisms for doing so may not be equivalent to using
the same namespace (I am not sure).
I never felt comfortable about
the fact that namespace URLs are not required to be resolvable. But
having some how accepted this fact, now I am not sure why we want to adopt
resolvability (specifically when there are no guarantees) and is the cost
of the same (requiring separate namespaces for each related artifact) worth
it? I think I may have missed some big debate somewhere about the
benefits of making namespaces resolvable, while the namespace specification
may continue to not require the same!
Can somebody closely familiar
with this issue shed some light here please!
Thanks,
Sanjay
-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Tuesday, May 11, 2004 12:59 PM
To: wsn@lists.oasis-open.org
Subject: [wsn] [Namespace URIs] Proposal to split the existing namespaces
Folks:
In [1] I proposed a mapping from the namespace URI convention used in version
1.1 of WS-notification specs to one based on the OASIS file naming and
related URI namespace conventions.
The submitted version of WS-Notification used a single URI namespace per
specification for both the XSD and WSDL. Given that we are trying
to adopt a direct mapping from URI to URL for our XSD and WSDL, we should
change this pattern to having separate URI namespaces for the XSD and WSDL.
Does anyone object to adopting this change in namespace URIs for the 0.1
draft of the OASIS work on WS-Notification?
[1]http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/6710/Proposed%20WS-Notification%20URIs.2.doc
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]