Re: [ubl] A Prototype Schema for UBL Models

Title: Message

Bill

 

That's pretty much what I did. I just used UBLish 
to get the naming rules

included then decided that this wasn't so 
appropriate and realised we

have almost all the 'tag' names already worked out 
in the CCP Schema

which I obtained by importing the CCP Schema 
into my UBLish-generated

skeleton Schema. So all we have new is the 
structure based on a simple

model of 
ABIE----ASBIE(0..n)----ABIE(1..1)---

                 |____BBIE(0..n)         
|___

 

The major part of the Schema is taken by the 
imported CCP Schema which

was hand-crafted in the first place 
(but closely maps to our spreadsheet

column names).

 

Any changes to 'columns' e.g. for customization 
requirements could be

made in the CCP Schema (by customization 
derivation) and then the 

new Schema imported into a new version of this 
model schema to

avoid duplication. To further avoid duplication, 
the spreadsheets could

be generated from the model schema too (generating 
the CCP from the

spreadsheets would be possible, I guess, but we 
have better controlled

names in the CCP it seems to me at the moment so 
preserving these

seems best to me).

 

I agree though that just mapping the spreadsheet to 
XML using the

Excel output generator is simple. We discussed in 
ISC that that was

a proprietary solution depending solely on a 
proprietary format/wizard.

This way we have a more standards (CCTS) 
related/derived format

based on the actual UBL deliverable of the 
CoreComponentsParameters

Schema Module, based on CCTS, with potential 
for simple upgrade and lack of

duplication. I think this makes a better foundation 
for what could be a lot

of standards work (if used for 
customization/context methodology).

 

Customization could be implemented by adding extra 
BIE's for changes

to cardinality, renaming, etc and using the 
resulting instances with the

eventual context applying mechanism or just simply 
to generate new

Schemas with a relevant tool (which could be an 
XSLT stylesheet or a tool

based on an XSLT stylesheet, or one using a 
script, or ...etc). i.e. it is

simplified and fairly well standardized. I know 
people might hate me adding this

but...  the transformation(s) from 
Model/CCP-based instance to

XSD could even be somewhat standardized! Perhaps 
including a context 

mechanism.

 

All the best

 

Steve

  
----- Original Message ----- 

  
From: 
  Burcham, Bill 

  
To: 'Stephen Green' ;  

  
Sent: Tuesday, May 25, 2004 12:40 
PM

  
Subject: RE: [ubl] A Prototype Schema for 
  UBL Models

  

  
I 
  did one of those for UBL about 16 months ago.  See the attached (and 
  perhaps oddly named) UMLModel.xsd.

  
 

  
At 
  that time, I used to load the UBL model (spreadsheet) into Excel (the new 
  version -- that outputs XML) and then I'd save it as XML.  I used the 
  attached stylesheets to convert from Excel's proprietary vocabulary into the 
  "UMLModel" one by running them in this order:

  
 

  
fatten-excel -> spreadsheet-to-UML-model-no-asoc -> 
  resolve-association-ends -> define-associations

  
 

  
normalize-identifier is a utility called from the other 
  transforms.

  
 

  
The 
  value I saw of this over XMI was that the vocabulary was more tailored to the 
  modeling language we'd chosen for UBL -- so there was a tighter fit.  
  Also, the vocab is considerably smaller (though less well documented :) than 
  XMI so it was presumably easier to learn.

  
 

  
I've 
  got some additional pipelines that fit on the end of this one to generate 
  pictures of UBL too.  Well, _old_ UBL.

  
 

  
-Bill

  
    

    
-----Original Message-----
From: Stephen Green 
    [mailto:] 
Sent: Monday, May 24, 
    2004 5:53 PM
To: 
Subject: [ubl] 
    A Prototype Schema for UBL Models

    
I wonder if this will be of interest to the UBL 
    TC.

    
 

    
This was discussed a while ago in an ISC 
    meeting.

    
 

    
I've prototyped a Schema for the UBL models, 
    based on the ccts:CoreComponentsParameter Schema Module, which it 
    imports.

    
(both attached)

    
 

    
I guess it could be used as an alternative 
    means of storing the model

    
data in a non-proprietary (XML) format 
    from which it could be

    
transformed, perhaps into a variety of other 
    formats, including 

    
Schemas, perhaps forms and even perhaps class 
    diagrams.

    
Of course it could be transformed to and from 
    spreadsheets too and

    
other proprietary formats. As such it could be 
    of interest to tools

    
 

    
but it might help towards solving 
    customization/context problems too

    
with regard to autogeneration.

    
 

    
All the best

    
 

    
Steve