[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Adoption Group?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]