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


Tim,

Tim McGrath wrote:
> 
> 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.

And I believe that this is a best outcome.
 
> 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.

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

Agree. And as far as I understand him, this seems to dovetail
with what Mike is saying as well. If the base UBL model is kept
distinct from the chosen UBL canonical form, then there are
other solutions that can be easily derived from the same model.

Phil

 
> Phil Griffin wrote:
> 
> > 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