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

[John Larmouth <j.larmouth@salford.ac.uk>]

As I commented on the ebTWG list on this same subject, you can try to be
syntax neutral (which is hard if you are going to be formal and machine
reeadable and processable) or you can give representations in a wide
variety of syntaxes so that syntax neutrality comes out from the law of
large numbers.

On this discussion, the issue is not so much syntax, but rather the
notation to be used to define the syntax (the aim is XML as the final
result, and I won't question that for now).

I am aware that there is a will (and expertise) in the UBL SC to provide
ASN.1 definitions to parallel the XSD definitions.  If these two can be
progressed on an equal basis, a strong degree of syntax neutrality is
assured, including the ability to provide instance communications in
binary as well as in XML mark-up.

The serious danger is that the base definitions are done by people with
one particular syntax in mind, which can render use of other syntaxes
non-optimal.

John L


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

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@salford.ac.uk
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England				Fax: +44 161 928 8069