Alex,
Since we hashed this out between us, if the proposed resolution is
acceptable to the team please go ahead and resolve this. No need to
wait for me.
Thanks, Prasad
Alex Yiu wrote:
Hi,
After exchanging some more emails with Prasad, I guess we may want to
consider the following approach: (a) Edtiors shall copy changes from
XSD files back to the Word doc manually, in order to make them in sync.
(b) When we provide download for review, we shall provide a zip file of
the main spec file + 3 XSD files
(c) Before the finalization of the spec, if any discrepencies (caused
by manual mistakes) happens between the main spec and XSD files, the
XSD files would be primary source of truth.
I guess we shall discuss this editing process issue more in the
next-next editors conf call, after Prasad's vacation. [ Prasad ...
again have a happy vacation. :-) ]
Thanks!
Regards,
Alex Yiu
Diane Jordan wrote:
Yes, there is public access to the
our
CVS site - I sent an email a couple months ago with directions. Let
me know if you want me to find it again.
Regards, Diane
IBM Dynamic e-business Technologies
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123
Hi, Prasad,
Few extra points for you to consider:
(A)
Does the TC/public have the read-only access to our WEB CVS system now?
If so, WEB CVS would be even a more powerful tool to let users track
the
changes of XSD file.
Even, if they don't have access to CVS, we even can save the DIFF from
the website as HTML file, whenever we publish the XSD files.
We can even bundle the main spec file HTML/MS-WORD with all XSD related
files in one single zip file if we want. That will ease our reviewers a
lot!
(B)
One thing I would like to point that: mistakes were made in the past
due
to the notorious automatic quotation formatting features of MS Word to
the make XSD files not-well-formed. I think frequent simultaneous
editing
to the XSD file outside Word doc and inside Word doc would be as error
prone as before.
Also, detailed reviews process of XSD files are likely to be done
through
plugging the XSD into a XSD tool env and start playing with it. Eye
inspection
of XSD files are just for eye inspection. :-) Again, eye inspection
only approach has failed us in the past.
And, if there is discrepencies between the XSD in WORD and the
standalone
XSD file during our manual simultaneous editing, which one is the real
one?
I hope I have convinced you by now. :-)
Regards,
Alex Yiu
Prasad Yendluri wrote:
Alex,
My apologies but, I strongly feel we should make the changes to the
schema
explicitly visible. Just handing a new version of the schema where
folks
need to go figure what changed since last version is unreasonable and
unwanted
IMO.
We want separate schema file so that we can validate the schema via
tools
designed for that and make sure the changes in the spec do not render
schema
invalid but, that does not obviate the need for the TC (and public at
large)
to view and review what changed in the schema as well, each time we
make
a new revision of the spec available for review. I like to think we are
schema experts :) and public should trust us but, as a principle I am
against
abstracting the changes made to the schema there by inhibiting a proper
review of the spec and schema.
If it is any help in mitigating the labor on the editing side, I would
be happy to assist with the schema changes if needed and useful.
Regards, Prasad
-------- Original Message --------
Hi,
Yes, spec-editing group will be a better email list to discuss this
issue. :-)
Sorry ... Prasad ... I still kind of prefer just having a pointer
in
the appendix to ask reader to refer to XSD file. When the spec is close
to be a finished stage (e.g. community draft? I forgot the exact term),
then we will copy the XSD back to the spec WORD doc.
I don't see any particular advantage of having two copies of XSD
floating around, when we are still in the stage of modifying XSD
quite
frequently. It creates unnecessary overhead for the editing group
(particularly me, selfishly speaking) to do any manual replication of
the content or 2PC.
(At the same time, we all agree that having a separate XSD file make it
easier for us to plug the XSD into any Schema tools / env).
In order to speed up our editting work, I would say we should minimize
any unnecessary overhead when possible.
I hope this makes sense to you. :-)
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
> Hi,
>
> We should make a point to update the schema in the spec (word
> document) whenever the schema files are updated. What I have
uploaded
> is the latest version of the spec in the word document checked in,
> converted to HTML (that is what we always do).
>
> If the latest schema needs to be in the HTML version, it needs
to be
> incorporated into the word version. Whoever updates the schema
files
> (maintained separately) in the CVS must also make sure to update
the
> schema in the word document as well.
>
> FWIW I did make schema changes related to my updates in the word
> version. So, some of the changes are reflected but, we need to
keep
> the schema in the word version always synched up with the
separately
> checked in schema files. My understanding is that one of us
(Alex?)
> has ownership of this aspect.
>
> Regards, Prasad
>
> Alex Yiu wrote:
>
>> Hi,
>>
>> Here are the 3 XSD files (which are in sync with the text in
the
>> recently uploaded spec HTML file)
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8470/wsbpel_main-July-30-2004.xsd
>>
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8471/wsbpel_msgprop-July-30-2004.xsd
>>
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8472/wsbpel_plinkType-July-30-2004.xsd
>>
>>
>> (Please note that: the XSD appendix in the HTML file has not
>> reflected changes in the XSD file)
>>
>> Since we have put the XSD into the CVS for a number of
revisions
of
>> changes already, I will remove the XSD in the appendix to
avoid
any
>> further confusion, when I got the pen next time in the editing
>> sub-group. I believe we shall use only the XSD files as the
source
of
>> truth for XML Schema until the spec moves to a reasonable
stage
with
>> very few anticipated XSD changes.
>>
>> Thanks!
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>> pyendluri@webmethods.com
wrote:
>>
>>> Information about the document
>>> wsbpel-specification-draft-July-30-2004.html has been
modified
by
>>> Prasad Yendluri (pyendluri@webmethods.com).
>>>
>>> Document Description:
>>> July 30 2004 version of the WS-BPEL TC editors draft
specification.
>>>
>>> Download Document:
>>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8468/wsbpel-specification-draft-July-30-2004.html
>>>
>>>
>>> View Document Details:
>>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.php?document_id=8468
>>>
>>>
>>>
>>> PLEASE NOTE: If the above links do not work for you,
your email application
>>> may be breaking the link into two pieces. You may be
able to copy and paste
>>> the entire link address into the address field of your web
browser.
>>>
>>>
Alex Yiu wrote:
Hi,
Yes, spec-editing group will be a better email list to discuss this
issue.
:-)
Sorry ... Prasad ... I still kind of prefer just having a pointer
in the appendix to ask reader to refer to XSD file. When the spec is
close
to be a finished stage (e.g. community draft? I forgot the exact term),
then we will copy the XSD back to the spec WORD doc.
I don't see any particular advantage of having two copies of XSD
floating
around, when we are still in the stage of modifying XSD quite
frequently.
It creates unnecessary overhead for the editing group (particularly me,
selfishly speaking) to do any manual replication of the content or 2PC.
(At the same time, we all agree that having a separate XSD file make it
easier for us to plug the XSD into any Schema tools / env).
In order to speed up our editting work, I would say we should minimize
any unnecessary overhead when possible.
I hope this makes sense to you. :-)
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Hi,
We should make a point to update the schema in the spec (word document)
whenever the schema files are updated. What I have uploaded is the
latest
version of the spec in the word document checked in, converted to HTML
(that is what we always do).
If the latest schema needs to be in the HTML version, it needs to
be incorporated into the word version. Whoever updates the schema files
(maintained separately) in the CVS must also make sure to update the
schema
in the word document as well.
FWIW I did make schema changes related to my updates in the word
version.
So, some of the changes are reflected but, we need to keep the schema
in
the word version always synched up with the separately checked in
schema
files. My understanding is that one of us (Alex?) has ownership of this
aspect.
Regards, Prasad
Alex Yiu wrote:
Hi,
Here are the 3 XSD files (which are in sync with the text in the
recently
uploaded spec HTML file)
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8470/wsbpel_main-July-30-2004.xsd
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8471/wsbpel_msgprop-July-30-2004.xsd
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8472/wsbpel_plinkType-July-30-2004.xsd
(Please note that: the XSD appendix in the HTML file has not reflected
changes in the XSD file)
Since we have put the XSD into the CVS for a number of revisions of
changes
already, I will remove the XSD in the appendix to avoid any further
confusion,
when I got the pen next time in the editing sub-group. I believe we
shall
use only the XSD files as the source of truth for XML Schema until the
spec moves to a reasonable stage with very few anticipated XSD changes.
Thanks!
Regards,
Alex Yiu
pyendluri@webmethods.com
wrote:
Information about the document
wsbpel-specification-draft-July-30-2004.html
has been modified by Prasad Yendluri (pyendluri@webmethods.com).
Document Description:
July 30 2004 version of the WS-BPEL TC editors draft specification.
Download Document: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8468/wsbpel-specification-draft-July-30-2004.html
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.php?document_id=8468
PLEASE NOTE: If the above links do not work for you, your email
application
may be breaking the link into two pieces. You may be able to copy
and paste
the entire link address into the address field of your web browser.
To unsubscribe from this mailing list (and be removed from the roster
of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|