Re: [ubl] The Current UBL 2.0 NDR draft document

[jon.bosak@sun.com]

Sylvia,

I'm sorry you sent your message before I had a chance to send out
the rest of the minutes, which will take another couple of days
because of other work I have to do.  I believe you misunderstand
what's been happening.

 - To my knowledge, no changes have been made to the NDRs that
   would affect FX operation.  We discussed this specifically in
   the meeting, and it's our understanding and belief that Peter
   can generate another set of schemas based on the rules you've
   already incorporated in your product per the NDRs of 19 July.
   So I don't think that GEFEG will have to "consider any changes
   or additions to FX that were not included in the draft NDR
   document dated July 19, 2006" because I don't think there are
   any.

 - With regard to the IND rules -- they haven't changed much since
   1.0.  With two exceptions, they have just been moved from one
   normative document to another and given a little editorial
   polishing.  We took the IND rules out of the Schema and Design
   Rules because they are not, in fact, rules for naming or schema
   design, and we moved them to a new Section 7 of the UBL 2.0
   document following the schema-defined normative instance
   constraints because they are, in fact, non-schema-defined
   normative instance constraints.  But this editorial change has
   nothing to do with schema generation.

 - IND7, a recent addition, was removed after two long, intense
   discussions about the meaning and use of the new UBL version,
   subset, and profile ID elements.  The decisions we made were
   consciously designed to leave the PRD2 schemas unchanged, so
   there should be no impact on FX from this item.

 - IND4 was removed for a reason I don't find documented in my
   notes, but I'm sure the NDR editors can explain once they get
   home.  It obviously has no effect on schema generation.

UBL greatly appreciates the dedication and patience of GEFEG as we
develop our standard.  It is our duty to ensure that your
reputation as leaders in your market is not jeopardized by any
misdirected communication of requirements.  As you will understand
from your experience in this area, we have to accomodate all
comments and issues as they emerge as part of the development
process.  In this case, it may be that the scope and effect of
documentary changes have been miscommunicated, and hopefully this
is now clearer.

As I said, I know of no changes made at the TC meeting in
Montréal this week that would affect the operation of the
current schema generation software.  If I'm forgetting something,
I trust that members present will correct me.  And if GEFEG can
find any operational effect from changes made at the meeting, I
trust that you will so inform us.

Jon

==================================================================

Date: Fri, 18 Aug 2006 13:55:27 -0700
From: Sylvia Webb <swebb@gefeg.com>
Subject: [ubl] The Current UBL 2.0 NDR draft document
To: ubl@lists.oasis-open.org
Cc: "'Michael Dill'" <dill@gefeg.com>, "'Frank Dreisch'" <dreisch@gefeg.com>,
        "Kruppke, David" <kruppke@gefeg.com>

Jon,
 
The substantive NDR changes made at the Montreal F2F meeting this week
removing IND rules, the decision to create another normative document for
IND related rules where no draft document exists, and the TC's decision not
to follow the agreement documented in the November 17, 2004 Santa Clara F2F
minutes where it was agreed that NDR were in the critical path of FX
development and must completed first, please be advised of the following
revision to GEFEG's policy concerning UBL 2.0 development.
 
GEFEG will not consider any changes or additions to FX that were not
included in the draft NDR document dated July 19, 2006 until after all
normative UBL 2.0 documents have been approved and published by OASIS as
final specifications.
 
We deeply regret having to come to this position. It is obvious however that
we cannot develop and maintain commercial quality products that our
customers expect and demand if we continue to chase the frequently changing
technical dreams of UBL developers which cost us significant resources and
have no mainstream customer demand.  
 
Best regards,
Sylvia