[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-lcsc] Global attributes and publishing markup
3CCEC62E.83357C39@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-s pecific 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 subscrib e or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
.
-- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC