[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] looking for practical examples
I kind of agree with Alexander: There are other factors which will determine the design of accounting/purchasing systems/databases besides standards. However, in some cases I have a little experience that when a system does already use a standard for the right reasons it is tempting to apply it for other purposes too. If you are under pressure to learn and support XML, for instance, and you are asked to design an internal aspect of the system which doesn't necessarily need XML, you still tend to use XML anyway where you can - that much is well attested I would think. I have witnessed the same applying to the language of XML (not UBL in my experience but I see no reason it wouldn't also happen with UBL) used for the external messages - that it tends to get used internally for features it certainly wasn't desgined for. Sometimes it is even easier to change the system requirements rather than abandon use of the XML language (like UBL). Sometimes it is easier to turn a round hole into a square one just so it can take a square peg rather than look for a round peg. With UBL I would think this would happen all the more because there aren't many XML languages around for internal systems which are royalty-free and likely to have persistence in the long term. But, like Alexander, I think there are many who don't get much exposure to standards like UBL and just design databases the way they always have done, using RDBMS normalisation rules. And for file transfers between internal systems they would just use CSV. I don't see this going away - just coexisting alongside the more geeky and avant garde XML, even UBL, implementations. What is likely to happen though is that the XML geeks will be more and more designing the interfaces where XML is involved, even when one side of the picture is using RDBMS/CSV (even lagacy/Cobol/CSV or legacy/EDI). This means some legacy systems being in contact with UBL even before they use UBL for e-commerce documents. Legacy-ers will find it easier to agree to use the modern approach than to insist on the modern system using the EDI approach. They will like to tick boxes to say they do XML, WS/SOA, even UBL even though their main integration interfaces still involve CSV and maybe, externally, EDI. In the meantime, standard UBL might be adapted to meet more and more the internal requirements of inventory transfers, despatch requests, internal invoices, internal trading orders, purchase and sales orders, ledger journals, even personnel to payroll data transfers. These are not really the forte of UBL which seems to have been documents which are legal 'instruments' (I think) and have to have high profile rigorous standardisation. But they might get traction as potential standards anyway due to customer demand. I would think. If not in OASIS then maybe just between system and system, developer and developer. Improving the UBL-like language development experience might help this in the medium to long term but it is noticable that there's not too much short term need for it, I think. Best regards - Steve 2009/2/13 Alexander Whillas <whillas@gmail.com>: > 2009/2/13 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>: >> Internalizing external standards is an ambitious, but not unreasonable >> aspiration. > > So what your suggesting is that ALL businesses base all their data > modelling (Databases, spreadsheets etc) on UBL process design so they > can fit within the UBL "truth"? > > What if the standard doesn't fix the use case, such as in my instance? > What if business requirements change faster than standards? > > I think standards should model real world needs not the real world > conform standards. XML is about defining a common language for systems > to communicate. The HTML 3.2 standard was a description of what was > going on with browsers, a description of what had evolved by itself. I > think the W3C helped to refine this and guide HTML in the right > direction with XHTML but new ideas have to come from industry and then > be refined by standards bodys. > > my 2c > > alex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]