Next in thread → Next in month →

RE: [wsbpel] new issue: xsd target namespace and abstract profile URI

From
Charlton Barreto <>
Date
2006-05-17T20:14:30+00:00
ID
Thread
RE: [wsbpel] new issue: xsd target namespace and abstract profile URI
Date is used when specifying URIs on pre-
and post-release versions of a spec. For example, if we post a CD of this spec
on August 2006 we should use the following, for example, for the template
profile:

 

http://docs.oasis-open.org/wsbpel/2.0/process/abstract/profiles/template/2006/08/[...].xsd

 

When we release the spec as final, we’d
only need to update the month (I hope!):

 

http://docs.oasis-open.org/wsbpel/2.0/process/abstract/profiles/template/2006/10/[...].xsd

 

As far as I know we cannot use a
placeholder (i.e. :YYYY/MM”) when we release a CD. 

 

-Charlton. 

 

From: Alex Yiu [mailto:] 

Sent: Wednesday, May 17, 2006 1:09
PM

To: Danny van der Rijn

Cc: wsbpeltc; Peter Furniss; Diane
Jordan; Dieter Koenig1; Alex Yiu

Subject: Re: [wsbpel] new issue:
xsd target namespace and abstract profile URI

 

I agree with your comment that partnerlink should not be under process. A typo
during rushing the email on my side. 

On your first point on whether we need both version number and YYYY/MM for
profiles, I guess we could discuss a bit more, even though I tend to have both
for profiles. 

Thanks!

Regards,

Alex Yiu

Danny van der Rijn wrote: 

Why would we include both a version number and a
date?  IMO version suffices.

Also, it seems that partnerlink shouldn't be under process.  How about:

"http://docs.oasis-open.org/wsbpel/2.0/process/partnerLink/[...].xsd"

Alex Yiu wrote: 

Hi, 

-------------------------------

Background: 

During San Jose F2F, we passed a target namespace resolution (Issue 284) to
update the target namespace URI for Exec and Abstract Process to the following:

The namespace URI of executable process is updated from: 

"http://schemas.xmlsoap.org/ws/2004/03/business-process/"

to: 

"urn:oasis:names:tc:wsbpel:2.0:process:executable" 

The
namespace URI of partner link type declaration in WSDL is updated from: 

"http://schemas.xmlsoap.org/ws/2004/03/partner-link/"

to: 

"urn:oasis:names:tc:wsbpel:2.0:partnerlink" 

The namespace URI of abstract process is updated to: 

"urn:oasis:names:tc:wsbpel:2.0:process:abstract" 

[a]

Peter Furniss suggested whether we should use a de-referenable URI.
E.g. starting with "http://docs.oasis-open.org/wsbpel/...". 

I guess there are two kinds of NS URI. 

One kind is not associated with an XML Schema. (e.g. expression language URI) I
think we should stick with URN in those cases.

The other kind is associated with an XML Schema. (e.g. target NS for Exec and
Abstract BPEL). In this case, I am open to change from URN style to URL style
with a de-referenceable URI. (Starting with "http://docs.oasis-open.org/wsbpel/...")

(Example from another OASIS TC: 

  http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd)

If we want to pick this route, the URI will become something to following:

The namespace URI of executable process is updated from: 

"http://schemas.xmlsoap.org/ws/2004/03/business-process/"

to: 

"http://docs.oasis-open.org/wsbpel/2.0/process/executable/[...].xsd"

The
namespace URI of partner link type declaration in WSDL is updated from: 

"http://schemas.xmlsoap.org/ws/2004/03/partner-link/"

to: 

"http://docs.oasis-open.org/wsbpel/2.0/process/partnerLink/[...].xsd"

The namespace URI of
abstract process is updated to: 

"http://docs.oasis-open.org/wsbpel/2.0/process/abstract/[...].xsd"

[...] is not decided yet. We need to investigate whether there is a naming
convention for XSD files in OASIS. 

[b]

For the abstract profile URIs:

For Observable Behavior, I would suggest to update to:

"http://docs.oasis-open.org/wsbpel/2.0/process/abstract/profiles/observable-behavior/2006/MM/[...].xsd"

For Template, I would suggest to update to: 

"http://docs.oasis-open.org/wsbpel/2.0/process/abstract/profiles/template/2006/MM/[...].xsd"

By having these changes, the URI for both profiles and abstract process itself
look more consistent.

If we don't have XSD for profiles, then the "[...].xsd" would be
dropped. 

[c]

replace "MM" in profile with the real number for Month. Let us shoot
for "06"

I would suggest to formally pass the resolution for this topic once the XSD for
both Exec and Abstract Process and both Abstract Process Profiles got
finalized.

-------------------------------

Thanks. 

Regards,

Alex Yiu
Next in thread → Next in month →