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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Comments on UBL


>Maybe you should start trying to implement it. Get
>some experience on the coal face. :-)

>David


Thanks David, am trying to do just that :-) The first step
is nearly complete - a potentially suitable customisation
in beta ( SystML is kindly hosting it at http://www.systml.co.uk/xml/ 
- comments on that more than welcome). The next step is 
'just add software' - plus customers would be nice :-) 
Software development has started, perhaps slowly at first :-)

Hopefully the experiences gained will be valuable at some
point as feedback to the standards. Others have done this
already though and are now working with the UBL TC so
the reality gap might be closing more and more. My comments
about UBL/ATG2's attributes and my alarm about the
possibility of haing to cater datatypes without length restrictions
comes out of the initial experience of the design phase which
seems appropriate to your comment about what is 'in your face'
and I agree with that. It is frightening, which is why I'd attempt
to break it all down into separate smaller problems and solve
each in turn. Codelists was the first, which Ken has elegantly
worked on. Then identifiers, which the codelists work provides
for as a suggestion to extend the codelist use of schematron
or other secondary validation pass(es). Then we had discussions
about the restriction of string, etc in datatypes - with Joe on this
list (I think that is still very much open ended and CEFACT might
provide answers with their own qualified datatypes but that is
just one possible solution). Size might only be partly solved by
the subsetting/customisation methodologies. Complexity of the
whole bundle is an outstanding issue which I'm grateful you 
brought up. I've experienced problems with that via developers
new to UBL. I've had loads of time to think about it but it still
alarms me, even after having studied the specs and helped with
them for years. First thing then might be a need for a simplified
implementation guide but I'd not expect to have time for that
myself so I might just charge in and face the remaining issues
of design head-on. We haven't yet mentioned a key concept
which seems to be the need for formalising the business rules
for the implementaion guide or just for the rules engine(s).
They should probably be machine readable in their normative
form and maybe there is room to standardise these (something
I'd like to see started, much as UBL has started this with codelists).
This may take more work than the validation and manipulation
of the XML, codes, etc. Will we need to use CAM, say and would
a subset/profile of CAM suffice? CAM itself seems complex and,
like UBL, 'big' but if it can be used to reduce the effective size
of the UBL problem space then it might be that a combination 
of CAM and UBL is smaller than the sum of the parts :-)

Ontologies needed too ???  :-)

All the best
 
Stephen Green




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