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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

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

Title: Message
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
All the best
----- Original Message -----
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.
-----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

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