[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL Adoption Group?
Hi good morning, > 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. Mmm... as a developer I think such tolerance is not the task of UBL in a MVC paradigm, as the "Controller" should take care of this. The reason is an XML based system MUST NOT ignore validations expecially the 1st structural/lexical step (XSD) otherwise we return back to HTML. A tolerant system should use a filter befor validate (as proposed by KH) or just block the incoming instance and let the user to design a specific mapping to import it (an EDI practise). > > 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. I think the big problem is to pass the 1st XSD validation first, after this, softwares can easely deal with further value validations and let the user to fix data errors. The "filter-before-validation" seems to me a good idea also I think a unique XSLT could be able to make this task driven by the Subset XSD. > >> >> 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 > > Roberto Cisternino
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]