Re: [ubl-lcsc] Global attributes and publishing markup

[Phil Griffin <phil.griffin@asn-1.com>]

Michael,

I think the problem here stems from a solution specific 
approach that is beyond the stated need or desire for UBL
to define XML tag names - a good idea in my opinion. 

But there is now a push to incorporate the details of W3C
XML Schema Definition Language directly into the UBL model,
rather than keep them isolated and distinct from the business
model. The results I believe are causing the current concerns.

In my opinion, making the model schema specific instead of 
keeping it schema neutral makes the UBL model less abstract,
and may ultimately limit its use. It makes UBL less of the true
"universal" solution I had hoped for, and very much more of a
tool specific one.

Phil Griffin


Michael Adcock wrote:
> 
> Re Eve's comment:
> <quote>
> I think that binding-specific information, if carefully designed, can
> often be useful for more than just one syntax binding.  The tag name is
> 
> a perfect example!  But in any case, if such information doesn't reside
> 
> in the spreadsheet (or an associated spreadsheet), it must be applied
> by
> hand -- definitely not a good bargain!
> </quote>
> 
> On the subject of the "XML specific", or indeed any solution specific,
> things which need to be recorded, I believe strongly that they must be
> clearly identifiable as solution-dictated and not business-required
> items. My preference would be to actually keep these in a, hopefully
> thin, layer of an implementation-specific library. I can see the
> attraction of putting them, clearly identified, into the spreadsheet
> although I fear that it would only take a simple slip-up to really mess
> the whole thing up and make the spreadsheet solution-specific rather
> than solution-neutral.
> 
> Thinking along these lines, and noting the point about things specific
> to more than one solution also, I favour the idea of a separate
> recording place, as one would end up with a range of common-to-all
> solution-specific items, some that are shared by two or three solutions,
> and others which are unique to a particular solution. Any new emerging
> solution would want to / ought to look in a specific place for existing
> 'solution fixes' to see if a work-around has already been devised that
> will achieve what they need. So we would be able to manage re-usable
> 'solution fixes' as well as re-usable everything else! But, better to
> keep them apart...
> 
> regards
> 
> Mike Adcock
> Standards & Security Unit
> APACS - Association for Payment Clearing Services
> Mercury House, Triton Court
> 14 Finsbury Square
> London EC2A 1LQ
> Tel: +44 (0) 20 7711 6318
> Fax: +44 (0) 20 7711 6299
> e-mail: michael.adcock@apacs.org.uk
> 
> **********************************************************************
> The opinions expressed are those of the individual and not the company.
>   Internet communications are not secure and therefore APACS does not
>      accept legal responsibility for the contents of this message.
>   If the reader of this message is not the intended recipient, or the
> employee responsible for delivering this communication to the intended
> recipient, you are hereby notified that any disclosure, distribution or
>    copying of this communication is strictly prohibited.  If you have
>  received this communication in error, please notify us immediately by
>           telephone to arrange for its return.  Thank you.
> **********************************************************************
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>