OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

my assessment is that the majority support the desire to keep our logical model 'pure' and 'implementation syntax free'.  This makes it very similar to the CC metamodel.

but, this does not mean we cannot also define the specific extended attributes for an XSD implementation (ie a physical model) - we just ensure that the two are well separated yet stay aligned.

so, it is not a question of WHAT we want to do, its really just HOW we can best do it.

Phil Griffin wrote:

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:
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
hand -- definitely not a good bargain!

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...


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>


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