[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Are we losing out because of grammars?
I was hoping that the Core components group would be defining a set of building blocks that the industry verticals would be able to use as or enhance as needs required and the ebXML core would not try the agreegation other than to say that here are some common ways of throwing the building blocks together, i.e. a Order,An invoice. The key here being that the core components needs to define components that have broad acceptance and applicability and should always be humble enough to include hooks for extentions. Martin M.E. Roberts xml designer, BTexaCT 01473 643775 firstname.lastname@example.org -----Original Message----- From: Martin Bryan [mailto:email@example.com] Sent: 07 February 2001 15:44 To: firstname.lastname@example.org Subject: Fw: Are we losing out because of grammars? The following message from the xml-dev group seems very germaine to this group's work. Martin Bryan ----- Original Message ----- From: "Sean McGrath" <email@example.com> Sent: 7 February 2001 13:33 Subject: Re: Are we losing out because of grammars? > Single models (monolithic) fail in the real world not in the theoretical > world. > > In theory, people in a smoke filled room can agree a top-down > model of data interchange. In practice, the cannot. In theory, developers > can manage the state-space explosion inherent in processing > monolithic content models but in practice they cannot. > > I think the mantra that "content + presentation == document" is part > of the problem. > > In reality there are two main sub-divisions of "content": > "semantics + aggregation + presentation == document" > > Agreeing semantic elements (invoice, voltage, footnote) is far more > politically/technically feasible than agreeing aggregation elements (ledger, > TV set, Technical Manual). > > Moreover, I think a multi-dimensional XML modelling technique > in which the *expression* of the aggregation is itself an XML > instance, it a powerful and general modelling approach worthy > of consideration in many contexts. > > There are a number of analogies. All are useful to some degree > but break down if you push them too far... > > Polymorphism - a containership model in which the type of the > things contained is not relevant. > > Merchant Shipping - what has standardized? The design of > the ship or the design of the containers loaded on to the ships > and subsequently transported by truck/rail? > > Bottom Up Analysis - start by modelling the component units > of a system and work upwards towards ways of agregating > them together. > > Tupperware (tm) - A containership model in which content and > containers can be intermixed. The contents of the containers > is never modelled in the outer container(s). > > regards, > >
Powered by eList eXpress LLC