OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [Fwd: Re: V1.1 editing process]


More editorial notes for v1.1.  
(mail 2 of 3)

-------- Original Message --------
Subject: Re: V1.1 editing process
Date: Mon, 10 Sep 2001 16:14:13 -0700
From: "Arvola Chan" <arvola@tibco.com>
To: "David Fischer" <david@drummondgroup.com>,"Colleen
Evans" <cevans@sonicsoftware.com>,"Burdett David"
<david.burdett@commerceone.com>,"chris ferris"
<chris.ferris@east.sun.com>,"Brad Lund"
<brad.lund@intel.com>
CC: "Ralph Berwanger" <rberwanger@bTrade.com>,"Ian Jones"
<ian.c.jones@bt.com>,"Brian Gibb" <Brian_Gibb@stercomm.com>

I have updated the message header schema to conform to the
W3C recommended
version of XML Schema. In addition, files that used to be
imported from
http://www.ebxml.org/project_teams/transport have also been
updated. These
include:
  a.. envelope.xsd - updated namespace and changed
uriReference to anyURI.
  b.. xlink.xsd - updated namespace and changed uriReference
to anyURI.
  c.. xml-lang.xsd - updated namespace.
  d.. xml-dsig-core.xsd - replaced with file obtained from
www.w3.org/TR/xml-dsig-core-schema.xml
The updated message header schema, messageHeaderv1_1.xsd
references the
above files assuming that they reside in c:\ebxml. I have
tried to account
for changes called for by editorial changes submitted by
David Fischer but
it is possible that there may be omissions (so I need
feedback from David).

In addition, I have made in-place changes to the Word
document, with change
tracking enabled. The following is a list of editorial
changes attributed to
me and a summary of how they have been dealt with either in
the document or
in the XML schema:

        Issue#    Page# (in David's issue list)
  a.. 17        22        Done
  b.. 18        23        Done
  c.. 57        26        Done
  d.. 54        27        Need to publish XSD separately
  e.. 14        31        Require discussions
  f.. 19        35        Updated XSD
  g.. 81        94        Done
  h.. 82        95        Require discussions
  i.. 83        95        Done
  j.. 84        96        Not a problem in Word document
  k.. 85        96        Updated XSD
  l.. 86        97        Updated XSD
  m.. 87        97        Updated imported XSDs
  n.. 88        98        Updated XSD
  o.. 89        98        Updated XSD
  p.. 90        99        Updated XSD
  q.. 91        99        Done
  r.. 92        100      Done
For those changes that I have made inline, I have added
comments to indicate
their corresponding issue numbers in David's list.

Regards,
-Arvola

  -----Original Message-----
  From: David Fischer <david@drummondgroup.com>
  To: Colleen Evans <cevans@sonicsoftware.com>; Burdett
David
<david.burdett@commerceone.com>; chris ferris
<chris.ferris@east.sun.com>;
Arvola Chan <arvola@tibco.com>; Brad Lund
<brad.lund@intel.com>
  Cc: Ralph Berwanger <rberwanger@bTrade.com>; Ian Jones
<ian.c.jones@bt.com>; Brian Gibb <Brian_Gibb@stercomm.com>
  Date: Monday, September 10, 2001 3:18 PM
  Subject: RE: V1.1 editing process


  Colleen,

  I would like to see Option 2.  I think the editorial
changes can be
accepted by the lack of comment on the list.  If we could
make those first
and publish to the list (tracking on -- Option 1) then we
could accept all
changes (keep a copy for tracking) and then make the other
changes (tracking
on -- Option 2) and be ready for the F2F.  This may not
cover the schema but
Arvola has volunteered to own that.

  As you said on the call, having line numbers and suggested
changes is
really hard.  If it were me, I would rather have that
section with the
changes, tracking on.  Some of the changes are so
wide-spread that this will
mean having an entire chapter with the changes.  This is not
easy no matter
how we do it.

  What can I do to help?

  David Fischer
    -----Original Message-----
    From: Colleen Evans [mailto:cevans@sonicsoftware.com]
    Sent: Monday, September 10, 2001 2:00 PM
    To: Burdett David; David Fischer; chris ferris; Arvola
Chan; Brad Lund
    Cc: Ralph Berwanger; Ian Jones; Brian Gibb
    Subject: Re: V1.1 editing process
    Importance: High


    I apologize for the long email, but if this is going to
get done by the
f2f we need to establish how we're going to proceed, and get
the milestones
out to the full TC.  Otherwise it just isn't going to
happen.  So please
give this some thought.  We have to determine what we want
for the f2f,
taking into account what is realistic given the timeframes. 
We have no more
time to waste.  I'd like to have this finalized by tomorrow
so I can plan
accordingly.
    Since David B was the only one to reply to the proposal
I sent out Fri
(see original email below), I assume there are no other
comments.  So that
gives us the following milestones up to the f2f:

    9/13 Deadline for comment regarding editorial status for
issues (are all
issues marked as editorial, really just editorial)
    9/21 Draft distributed to full TC for review with all
editorial changes
made (V1.01?)
    9/27 Deadline for comment on draft V1.01
    10/3 Draft V1.01 changes accepted - new base version
(V1.02?) for f2f
meetings

    What I'm not sure about is where the non-controversial
changes (those
that don't need to be discussed at the f2f) fit.  In the
call today it was
suggested that "In two weeks (next call[9/24]), there will
be a final list
of changes.  Then Colleen will have a week to implement as
much as
possible." (from the minutes).   Thre are a couple of things
to consider:

    (1)  It's preferable to go into the f2f with a 'clean
copy' - meaning
all changes to date agreed upon and accepted.  Otherwise
it's difficult to
work with the document.  It's best to start fresh with new
line numbers,
etc.
    (2) Given #1 and assuming we want a full TC review cycle
before
accepting changes, we need to have ALL agreed changes we
want incorporated
for the f2f, editorial or otherwise, submitted by 9/15 so
that I have a week
to get V1.01 out by 9/21 for full TC review and comment by
9/27.  That gives
me from 9/27 - 10/2 to get V1.02 ready for the f2f, based on
the received
comments to V1.01.
    (3) This requires more than just a "final list of
changes", I need all
the text, examples, schema, revised figures, etc.
representing the agreed
upon approach for each issue by 9/15.

    Given this deadline of 9/15, we have two alternatives:
    (A) have just editorial changes by the f2f
    (B) have editorial and as many other changes made as
possible for the
f2f

    If we prefer alternative B our options are:
    Option 1:  Have V1.01 ready for the f2f with all
editorial changes and
any other revisions possible having been submitted by 9/15
and been through
a review cycle and accepted
    Option 2:  Same as Option 1, but add other proposed
revisions that have
not been through a TC review cycle indicated with tracking
on.
    Option 3:  We don't have a review cycle or accept
anything prior to the
f2f.  All changes are made with revisions on and we have a
massively revised
V1.01 going into the f2f.

    Personally, I think the last alternative sounds really
ugly.
    Colleen


    "Burdett, David" wrote:

      ColeenGenerally I agree with your approach. A few
minor tweaks.
        -----Original Message-----
        From: Colleen Evans
[mailto:cevans@sonicsoftware.com]
        Sent: Friday, September 07, 2001 9:15 AM
        To: Burdett, David; David Fischer; chris ferris;
Arvola Chan; Brad
Lund; Ralph Berwanger; Ian Jones; Brian Gibb
        Subject: V1.1 editing process
        Apologies if you discussed this on the Aug 27 T2
call I missed, but
I've been thinking about how to coordinate revisions for
1.1.  Here are a
few ideas for consideration / comment.  I suggest we refine
them within the
T2 team first, and then publish to the full TC.  Ralph, I've
copied you in,
as I'm sure you have some valuable insights into this
process having
coordinated it in the past.
        Step 1:
        David has set a deadline of Sept 13 for comment
regarding which
issues are purely editorial, and which require agreement of
the TC.  Once
that date has passed and the categories are finalized, I
will make all the
agreed editorial changes (by 9/21 - I'm on vacation 9/13 and
9/14), giving
us a base document to work with going forward into the major
revisions
phase.  I think 'someone' suggested this on our last TC call
- maybe Chris?

        Step 2:
        Once the editorial changes are made, I'd like to
send the document,
with revisions marked, out to the list with a deadline for
comment (maybe
9/27 or earlier?).  At the end of that period, I'd like to
accept all
changes in the document and start fresh for the next cycle. 
V1.01?.
Otherwise, the document is going to be so marked up, it will
be very
difficult to work with as major revisions are made.

        Step 3:
        Determine an owner for each of the major changes
(establish
ownership while Steps 1 and 2 are underway).  That person
will make all
required changes to the new, clean document from Step 2
(including examples,
figures, schema, etc., etc.) and submit a revised document
with their
changes to me by a TBD deadline.
        [David B] I think that rather than always submit a
revised document,
they could submit just a revised section (or sub-sections)
if the change is
localised

        If the changes are fairly minor, replacement text
with line numbers,
etc. might be appropriate rather than changes inline to the
document.   I
will coordinate pulling these revisions together, and I
anticipate that I'll
need at least a week to accomplish this after the submission
deadline.

        Step 4:
        Distribute revised document to the list and set a
deadline for
comment.

        Step 5:
        Final round of revisions based on comments completed
by ?

        Questions / potential issues

          a.. Line numbers will change before Step 3, so the
owners of each
issue will have to reconcile the new line numbers to the old
line numbers on
the issues list.  I don't see a way around this - as soon as
I start the
editorial changes, things will shift.
          [David B] I think we should also include sections
numbers to help
solve this.
          b.. Last time we went through this process it
seemed to work best
to have one person merge changes, rather than trying to
replace sections.
Does this still make sense, or is there a better approach?
          c.. What do we require for our f2f?  Is a clean
doc with all
editorial changes, major revisions pending, good enough?
          [David B] I think so
          d.. I'd like to get a volunteer to review and
refine all schema
and examples once the changes in step 3 have been made - a
sanity check on
how they all hold together. [ce] Arvola volunteered today.
          e.. Have we established yet which issues require
discussion at the
f2f?  Resolution of the more controversial issues will
obviously need to be
completed by the deadline established for Step 3.
          [David B] Not yet. I will though develop a list of
issues for the
T2 task.
        So throw your darts -  it's a start.
        Colleen
    --
    Colleen Evans
    Principal Product Manager
    Sonic Software Corporation
    phone:  720 480-3919 or 303 791-3090
    email:  cevans@sonicsoftware.com
    website:  http://www.sonicsoftware.com

messageHeaderv1_1.xsd

envelope.xsd

xlink.xsd

xml_lang.xsd

xmldsig-core-schema.xsd

ebMS_arvola.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC