Alex,
For one CVS is not an approved form (AIUI) for distributing the specs
or related contents by the TC. Hence the need to publish HTML version
instead of the word version we use for editing,.
I guess all editing is error prone and we just need to be careful or
one or the two folks that know the pit falls handle the word edits
along with the schema file edit (that they do now anyway). Since these
are incremental it is not a big deal IMO. All one needs to do is,
update the schema file first and when satisfied that changes are good,
copy and paste the text to relevant section in word.
The eye inspection is for viewing and reviewing what changed in the
schema and not for validating or playing with it. For the latter
aspect, we will provide the URI ref to the actual schema.
Cheers,
Prasad
Alex Yiu wrote:
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.
|