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] UBL Adoption Group?


I think you have identified an extremely important requirement. There 
does seem to be a general consensus that co-ordination is beneficial for 
everyone.

But there seem to be two aspects to your discussion -

1. producing guidelines that adopters of UBL can use to develop their 
customized implementations
and
2. creating a generic implementation profile

The UBL TC have taken responsibility for the first item.  We have had a 
draft for some time but now we have some practical experience and input 
'from the field' we intend to complete this in time for the next UBL 
Plenary in September.

As far as the second aspect goes, this could be approached in several 
ways. It could be through a formal process (as you suggest) either via a 
new OASIS group, part of the UBL TC or through another body such as 
CEFACT.  However, it may be sensible to allow a more evolutionary 
approach.  Rather than attempt to design a profile 'standard', we could 
loosely coordinate various implementations and from these distill a 
'best use practice' profile.  A version of this will hopefully be an 
outcome of the recently formed CEN/ISSS workshop on business 
interoperability interfaces for public procurement in Europe (CEN/ISSS 
WS/BII).   Although this is only focussed on government e-procurement 
within Europe (as has been noted),  it is a project attempting to align 
different UBL implementation profiles. So the process it follows may 
prove to be a worthy model for expansion to a global view.
Personally, I would be more inclined to keep it loose at this stage.  We 
are not at the stage of dealing with issues of 'official' verification 
and conformance testing to the profiles.  And maybe we dont need to be.  
In other words we can take a more laissez-faire approach where the 
market will refine and set its own commonality with some sheparding from 
forums like ubl-dev and the UBL TC.

I do agree with you that encouraging re-use and common profiling is an 
important part of what makes UBL an attractive package.  Indeed, support 
for adoption is really the major task for the UBL TC from now on. 


stephen.green@systml.co.uk wrote:
> While I still 'have the floor' I'd add that I would envisage
> the group taking input from groups like NES and OIO and CEN
> on any formally stateable business rules which can be (not
> necessarily by the group more than in prose for conversion
> to other forms later) asserted in a formal testable way. A bit
> like some of the W3C specs (such as the XForms spec which
> allowed the creation of the W3C XForms test bed) and even really
> like the UBL NDR which I believe NIST was able to use for the
> creation of a conformance test service (presumably with test
> assertions running behind it). But it would be focusing on
> those aspects which are global and general, like an upper
> profile as it were - perhaps it could link to an ontology for
> that matter if the ubl ontolog forum wsih to take on the work :-)
> It could link into various CEFACT groups on that basis. Perhaps
> involving the same folk as do that now, but with a global hat.
>
> --Stephen Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
> Quoting stephen.green@systml.co.uk:
>
>> Quick addition on behalf of G. Ken Holman (apologies as he is on 
>> vacation
>> and away from emails - well deserved I'm sure)
>>
>> Ken likes the idea of a member section (thanks Ken) but not 
>> implementation
>> testing (I think I agree) but emphasises the usefulness, and again I 
>> very
>> much agree, of such a formal profile stating rules (I hope testable ones
>> of course - though the testing itself being out of scope in some sense)
>> for what Ken calls the "calculation model behind the UBL instance". Ken
>> I believe is refering to the way that values are calculated within a
>> document and the need to define and formally document those 
>> calculations.
>>
>> Quoting Ken:
>> "UBL standardizes only the wrapper of values,
>> not the calculation of values so wrapped, and
>> each implementation will need to document
>> what their calculation model is, and it would
>> be neat if there were a formalism for
>> expressing the calculation model."
>>
>> That is Ken's input. Thanks Ken. The following is mine so don't be
>> confused :-)
>>
>> I must say this is one aspect I especially had in mind when considering
>> a group creating conformance definitions and profiles and the like
>> for UBL. I had been thinking there might be a need to gather conformance
>> issues (those beyond the scope of the TC say) and seek to solve problems
>> by filling gaps and clarifying ambiguities, etc by formulating and
>> documenting, normatively in terms of a profile, say any testable 
>> assertions
>> that can be made. (The Test Assertion Guidelines TC may be providing 
>> aids
>> to this.)
>>
>> Rather than burden the TC with this (it is quite an undertaking) it 
>> seems
>> prudent to consider creating what OASIS calls a Member Section which can
>> use OASIS facilities and be called an OASIS Member Section but functions
>> independantly. This could be an ongoing project with website, etc a bit
>> like the WS-I project which create profiles for Web Services 
>> standards for
>> the same kinds of reasons.
>>
>> There could be profiles for different messaging methods, say and liaison
>> could be sought with groups such as the Tax XML TC, perhaps. It could
>> achieve recognition in its own right while co-operating with both the
>> UBL TC and other groups and projects like CEFACT, CEN, NES, CODICE, etc.
>>
>>
>> --Stephen Green
>>
>> Partner
>> SystML, http://www.systml.co.uk
>> Tel: +44 (0) 117 9541606
>>
>> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>>
>>
>>
>> Quoting stephen.green@systml.co.uk:
>>
>>> Responses inline:
>>>
>>> Quoting roberto@javest.com:
>>>
>>>> Hi,
>>>>
>>>>> Here's an example which might demonstrate what I perceive
>>>>> (maybe) as the need:
>>>>>
>>>>> suppose two countries decide to only accept those elements
>>>>> which their national tax regulations require (and understand),
>>>>>
>>>>> if that was paper we were talking about there would be no
>>>>> likelihood of an invoice from another country being rejected
>>>>> just because it isn't fully understood or fully compliant with
>>>>> the receiver's country's tax regulations - it would be accepted
>>>>> if it complied with the sender's regulations and there would be
>>>>> provision for international trade laws and treaties I guess
>>>>>
>>>>> but if the localisation effort isn't too careful it could result in
>>>>> rejection of a UBL invoice for those very reasons - just because
>>>>> it doesn't fit the local subset
>>>>
>>>> I really hope that noone will base its validations on codelist 
>>>> "labels" or
>>>> "definitions". The code is the only real "data" fro data processing
>>>> purposes.
>>>
>>> Sorry, I wasn't here refering to codelists in particular. That's the 
>>> other
>>> thread. What concerns me in this discussion is how the subset of the 
>>> whole
>>> document might conflict with another subset. Better I thought to seek
>>> convergence on a single subset or 'Core Profile' as most standards 
>>> call it.
>>> This seems to be happening sufficiently genearlly to prove to me 
>>> that it is
>>> not only possible but that it will soon be discovered that all the 
>>> subsets
>>> lead to this 'core'. In the process though there could be a lot of 
>>> waste and
>>> conflicting concepts of minor aspects of the various subsets. There 
>>> could,
>>> for instance, be some subsets which disallow non-subset data and  
>>> others which
>>> tolerate it with some qualifications (like the 'must understand' versus
>>> 'can ignore' principles). These approaches haven't been aligned so 
>>> there
>>> are chances for conflicting systems which could probably be avoided 
>>> with a
>>> seeking of a common understanding and formalised approach.
>>>
>>> This might apply to codelists but there other issues occur which are 
>>> best
>>> sorted locally it seems. But there could be discussion about seeking 
>>> a core
>>> profile which includes both a broadly applicable 'subset' defining 
>>> the core,
>>> some rules about it's meaning and use and perhaps guidelnes or,   
>>> best, testable
>>> assertions about other matters such as codelists. Seeking to state this
>>> profile formally then allowing for more local profiles on top of it 
>>> would be
>>> like having a primary standardised schema such as we have and an   
>>> understanding
>>> about more localised second pass validation schemas and schematron. The
>>> core profile might include assertable normative rules about how to make
>>> conformant local profiles too. It could be a basis for conformance 
>>> testing
>>> outside of the group which defines it, to include perhaps both 
>>> conformance
>>> testing of the immediate implementations in the form of core profile
>>> products and services, etc and also conformance testing of possibly 
>>>   conformant
>>> local profiles, etc.
>>>
>>>>
>>>> It doesn't matter if definition localizations will be wrong (for a 
>>>> limited
>>>> time) as soon as the original code list has been correctly designed 
>>>> by an
>>>> agency or subset group.   This way the code will be always the 
>>>> right one
>>>> and probably end users will laught by reading the translation of the
>>>> label.
>>>>
>>>> There will be always the time to fix it.
>>>>
>>>>>
>>>>> so having some global view of things would help localisation
>>>>> specialists properly do their work and not go creating
>>>>> interoperability problems (indavertently) in their zeal to
>>>>> properly cater for their own area's needs
>>>>
>>>> For code lists a generic localizer should pay attention to do not 
>>>> modify
>>>> codes, an XSLT process could then compare the localization GC file 
>>>> with
>>>> the original GC to verify codes are keeped.
>>>>
>>>>>
>>>>> not that they would just ignore cross-border issues like
>>>>> receiving invoices from other areas of localisation and in
>>>>> other subsets
>>>>
>>>> This appears something to add to validation samples under "UBL open"
>>>> definition made by KH.
>>>> UBL Open is a system/application which is able to receive any UBL 
>>>> instance
>>>> even when data values do not pass the value validation step.
>>>> Such Open system could give the user the chance to deal with data 
>>>> errors
>>>> and fix them manually or elsewhere.
>>>>
>>>>>
>>>>> but they might benefit from warnings about what is best
>>>>> practise when creating a localisation - in practise
>>>>>
>>>>> and not all localisers are going to be sponsored by national
>>>>> governments or multinational vendors
>>>>>
>>>>> :-)
>>>>>
>>>>
>>>> Yes, I do italian localization personally... no money.
>>>>
>>>> I have to go now I will answer further mail tomorrow or later.
>>>>
>>>> Ciao
>>>>
>>>> Roberto
>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> Stephen Green
>>>>>
>>>>> Senior IT Officer
>>>>> Bristol City Council
>>>>> Room G34, Romney House
>>>>> Romney Avenue
>>>>> Bristol  BS99 3HB
>>>>> Tel: 0117 922 3794
>>>>> Fax: 0117 922 4877
>>>>> Email: stephen_green@bristol.gov.uk
>>>>>
>>>>>
>>>>>
>>>>>>>> "Stephen Green" <stephen.green@bristol.gov.uk> 24/05/07 16:58 >>>
>>>>> Don't there need to be 'guidelines' on how these large subsetting
>>>>> and profiling efforts like NES, CODICE, SBS and smaller ones like
>>>>> SystML2 (smaller in resoources, not scope) should provide for
>>>>> interoperating with eachother - for example over tax support?
>>>>>
>>>>> Codes, I agree, are for the vendors, ERPs and endusers to agree,
>>>>> maybe with some localisation effort help (though even here some
>>>>> measures to align such help might be of * major * value).
>>>>>
>>>>> But there is a lot more to UBL than codelists - and relying solely
>>>>> on a mixture of what the UBL could foresee and happy accidents
>>>>> (serendipity) between localisations and other subsets seems a
>>>>> bit overly risky for what is actually at stake.
>>>>>
>>>>> Is a customisation guide by the TC all it takes?
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> Stephen Green
>>>>>
>>>>> Senior IT Officer
>>>>> Bristol City Council
>>>>> Room G34, Romney House
>>>>> Romney Avenue
>>>>> Bristol  BS99 3HB
>>>>> Tel: 0117 922 3794
>>>>> Fax: 0117 922 4877
>>>>> Email: stephen_green@bristol.gov.uk
>>>>>
>>>>>
>>>>>
>>>>>>>> "Stephen Green" <stephen.green@bristol.gov.uk> 24/05/07 16:20 >>>
>>>>> Thanks Roberto
>>>>>
>>>>> But who is responsible for ensuring the localisations
>>>>> can interoperate, e.g. in cross-border trade (and
>>>>> surely the whole point of UBL is to facilitate such)?
>>>>>
>>>>> Best
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> Stephen Green
>>>>>
>>>>> Senior IT Officer
>>>>> Bristol City Council
>>>>> Room G34, Romney House
>>>>> Romney Avenue
>>>>> Bristol  BS99 3HB
>>>>> Tel: 0117 922 3794
>>>>> Fax: 0117 922 4877
>>>>> Email: stephen_green@bristol.gov.uk
>>>>>
>>>>>
>>>>>
>>>>>>>> <roberto@javest.com> 24/05/07 16:15 >>>
>>>>> hello,
>>>>> I think this is the job of Localization sub-committees,
>>>>> adoptions and customizations are driven by locale-based problems, 
>>>>> even
>>>>> when locale means "europe" thus not a specific country.
>>>>>
>>>>> Only Local estabilishments are able to obtain such locale information
>>>>> needed to a customization even when talking about an industry.
>>>>>
>>>>> But you are right we do not have a centre for adoptions (should be 
>>>>> UBL TC
>>>>> itself).
>>>>>
>>>>> Also we do not have an LSC for each country/language yet.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Roberto Cisternino
>>>>> UBL ITLSC
>>>>>
>>>>>> Greetings again UBL-DEV members,
>>>>>>
>>>>>> I'm wondering if anyone would be interested
>>>>>> in the idea of establishing a UBL Adoption
>>>>>> Group - perhaps as an 'OASIS Member Section'
>>>>>> http://www.oasis-open.org/who/ms-overview.php
>>>>>>
>>>>>> I've absolutely no idea of the costs, etc and
>>>>>> overheads of doing this, nor have any commitment
>>>>>> to being able to follow it through.
>>>>>>
>>>>>> I just wondered what interest there might be.
>>>>>>
>>>>>> My idea would be to use it to look at anything
>>>>>> like adoption facilitation e.g. profile definitions
>>>>>> - such as turning subsets and profiles defined
>>>>>> for specific needs into ones targeted at broader
>>>>>> audiences and maximal interoperability. And
>>>>>> seeking to support alignment of subsets and
>>>>>> profiles defined outside UBL.
>>>>>>
>>>>>> I guess certification would be out of scope but
>>>>>> maybe there would be scope for defining
>>>>>> conformance requirements of aspects of UBL
>>>>>> not covered in the specs or establishing any
>>>>>> needs for profiles and customisations.
>>>>>>
>>>>>> It could reference work from other groups like
>>>>>> the new OASIS TAG TC and the UN/CEFACT
>>>>>> COD group.
>>>>>>
>>>>>> I'd be pleased to hear from anyone interested,
>>>>>> on or off list, and hopefully keep those who
>>>>>> contact me abreast of developments. That's
>>>>>> about all I could commit to personally at the
>>>>>> moment though and there are no funds I'm
>>>>>> aware of to help. Just in case this makes sense
>>>>>> to enough people though.
>>>>>>
>>>>>> All the best
>>>>>>
>>>>>> Stephen Green
>>>>>>
>>>>>> stephengreenubl@gmail or details as below
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> Stephen Green
>>>>>>
>>>>>> Senior IT Officer
>>>>>> Bristol City Council
>>>>>> Room G34, Romney House
>>>>>> Romney Avenue
>>>>>> Bristol  BS99 3HB
>>>>>> Tel: 0117 922 3794
>>>>>> Fax: 0117 922 4877
>>>>>> Email: stephen_green@bristol.gov.uk
>>>>>>
>>>>>>
>>>>>>
>>>>>> ______________________________________________________________________ 
>>>>>>
>>>>>> Please note the new simpler name for our website:
>>>>>> http://www.bristol.gov.uk
>>>>>>
>>>>>> Our email addresses have also changed - visit
>>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>>
>>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Roberto Cisternino
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>>
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>> ______________________________________________________________________ 
>>>>>
>>>>> Please note the new simpler name for our website:
>>>>> http://www.bristol.gov.uk
>>>>>
>>>>> Our email addresses have also changed - visit
>>>>> http://www.bristol.gov.uk/bigchange for further details.
>>>>>
>>>>> Sign-up for our email bulletin giving news, have-your-say  and event
>>>>> information at: http://www.bristol.gov.uk/newsdirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>>
>>>>>
>>>>
>>>>
>>>> Roberto Cisternino
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.Version: 7.5.467 / Virus Database: 
> 269.7.7/816 - Release Date: 23/05/2007 3:59 PM
>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath



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