Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

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