Re: [ubl] A Prototype Schema for UBL Models

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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' ; ubl@lists.oasis-open.org

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:stephen_green@seventhproject.co.uk]
Sent: Monday, May 24, 2004 5:53 PM
To: ubl@lists.oasis-open.org
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