AW: [ubl] Using CCs correctly (was Re: [ubl] Review of Two Diffs (Michael/Sue's and Stephen's))

MHonArc v2.5.0b2 -->

ubl message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: AW: [ubl] Using CCs correctly (was Re: [ubl] Review of Two Diffs (Michael/Sue's and Stephen's))

From: "Michael Dill" <>

To: "'Tim McGrath'" <>,<>,"Jon. Bosak@Sun. Com \(E-Mail\)" <>

Date: Thu, 1 Jul 2004 13:43:21 +0200

I'd 
like to add a further point to this pre-Copenhagen discussion: If we do not 
restrict the reuse of reusable aggregates (ABIE) - where appropriate - we will 
have huge documents, and users will have the same problems they already have 
with the application of standards like RNet or oagi. 

 

It's 
very difficult for an user to figure out which of the 500000 to 
700000 document elements are the right ones to map his 30-40 elements to. In 
other words, the CCTS methodology prevents to build data church yards. 

 

Imho 
this is one of the big advantages of CCTS to combine redundancy free data 
definitions and structures with context related 
restrictions.

 

This 
requires underlying ABIE or CC, what we do not yet have 
everywhere.

 

I 
would not consider this as a problem, as long as UBL just wants do develop a 
simple data set just for simple documents. But what I see is, that people come 
up with complex documents and complicated requirements. This will undoubtfully 
lead to the extension of existing ABIE in reusable and to an useless extension 
of ALL documents which use the aggregates of the reusable library - except we 
restrict the inherited extensions where they are not to be 
used!

 

This 
also asks for a change log in the ss (I've just learned from Anne's issue list 
that this is an abbreviation) referring to not yet fully existing formalized 
DMRs. Thus we can maintain data and DMRs in a master and do not have to have 
them in the schemas.

 

I seem 
to remember that somebody asked whether UBL wants to become a standard 
organization or so. Maybe the above mentioned questions are exactly among those 
a standard organisation has to deal with.

 

Best 
regards,

Michael Dill

 

 

 

  
-----Ursprüngliche Nachricht-----
Von: Tim McGrath 
  [mailto:]
Gesendet: Donnerstag, 1. Juli 2004 
  04:56
An:   
Cc: 
  
Betreff: [ubl] Using CCs correctly (was Re: 
  [ubl] Review of Two Diffs (Michael/Sue's and 
  Stephen's))

so what can we do about it? where are the CCs 
  we should be basing this on?  we stated up front that all unqualified 
  BIEs in UBL would be candidate core components and have submitted them to 
  TBG17 on that basis.  

I accept that despite numerous reviews and 
  discussions we did not always agree on the use of qualifiers or terms, but as 
  we have no consistent examples or definitions in the CCTS we are feeling our 
  way as to how these should be used.  pehaps you can help 
  us?

 wrote:

  
    
    
Tim,

    
 

    
* what do you mean by 'the library of 
    CCs'?  - i am not aware there are any.  

    
 

    
Exactly, 
    thats the fundamental problem.  Without defining and basing all of your 
    BIEs on CCs you are 1) non conformant with CCTS and 2) unable to have the 
    underlying structures that are key to any harmonization and approval 
    process.

    
 

    
* what do you mean by 'consistency in the use of qualifiers vs. 
    multi-worded object classes and property terms'?  - i thought we had 
    introduced property term possessive nouns and nouns to try and deal with 
    this more formally than the CCTS itself.

    
First, 
    the property term possessive nouns and nouns are 1) not CCTS 2) confusing to 
    the model, and 3) were not implemented uniformly.  Second, there appear 
    to be zero qualifiers used for the object classes - rather a host of 
    unqualified object classes have been defined for the 
    reusables. 

    
 

    
Mark
Mark 
    R. Crawford

    
Senior 
    Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet 
    Representative
Vice Chair - OASIS UBL TC & Chair Naming and Design 
    Rules Subcommittee
Chair - UN/CEFACT XML Syntax Working Group
Editor - 
    UN/CEFACT Core Components

  

    
LMI Government 
    Consulting
2000 Corporate Ridge
McLean, 
    VA 22102-7805
703.917.7177 Phone
703.655.4810 
    Wireless
The opportunity to make a difference has 
    never been greater.

www.lmi.org