http://ofbiz.116.s1.nabble.com/XSD-schema-conversion-anyone-tp170452p170460.html
>
> That's a little bit different then...
>
> What you probably need/want is some code to take in
> the incoming ONIX
> files and map the information to existing OFBiz
> entities rather than
> creating new ones.
>
> As you're doing the mapping you'll get into the
> issue you brought up
> here about what should go where. Different things
> will most likely be
> best handled in different ways. For example, the
> "publisher" would be
> handled well by a ProductFeature, but the title and
> ISBN would not as
> they are unique to each book. Those could be put
> into ProductContent
> records (with new ProductContentTypes) and handled
> with existing
> code, or perhaps even just added as fields to the
> Product entity, and
> then only small changes would be needed in the
> ProductSearch code (or
> no changes... it's been a while since I wrote it so
> I don't remember
> exactly).
>
> In any case, I think you'll find pretty flexible and
> efficient
> performing search capabilities in the ProductSearch
> stuff. Make sure
> you're looking at a moderately recent version of
> OFBiz (ie not one of
> the ancient releases, like 3.0.0 or something).
>
> -David
>
>
> On Aug 8, 2006, at 12:43 AM, Iain Fogg wrote:
>
> > David,
> >
> > Basically I'm looking to augment the standard
> OFBiz functionality
> > with functionality specifically required in the
> book selling
> > business. As an absolute minimum, I need to be
> able to periodically
> > refresh the OFBiz product and supplier data with a
> subset of the
> > ONIX data (new titles, price changes, supplier
> info, etc). I also
> > want to look at ways of providing a richer set of
> search options
> > specific to the book trade (eg, title, publisher,
> ISBN, etc), and
> > to have all of the ONIX data available for
> back-office (and
> > sometimes front-of-house) enquiries.
> >
> > I've seen it suggested that one of the ways to
> provide richer
> > content in the OFBiz Product database is to use
> the Feature
> > mechanism. I've played around with this a little
> bit, and it might
> > work, but I'd need to be convinced about
> performance and
> > maintainability. The ONIX dataset can contain
> hundreds of thousands
> > of records, and modelling these with the OFBiz
> Feature feature
> > seems a bit clumsy. I'm not sure what the impact
> would be on search
> > queries.
> >
> > I'm still exploring my requirements, and at this
> stage about the
> > only thing I know for sure is that I need to synch
> ONIX data with
> > OFBiz to ensure OFBiz is using up-to-date info.
> Probably the other
> > thing I know for sure is that I need richer search
> options, and
> > response needs to be reasonable.
> >
> > At the end of the day, one of the things I need to
> work out is how
> > to "integrate" (and I use the term loosely), ONIX
> and OFBiz.
> >
> > Cheers, Iain
> >
> >
> > David E. Jones wrote:
> >
> >>
> >> Is the intent to map it to the OFBiz data model
> or services? I'm
> >> guessing that's not the case if you're trying to
> create entities
> >> to represent it.
> >>
> >> If you're trying to create a data model for an
> XML Schema and not
> >> mapping it to an existing data model, then you'll
> have to design
> >> a data model to match it. XML is an hierarchical
> data structure
> >> which is very different from a relational
> (table-based) one. Some
> >> design will have to be done to decide how to
> structure things
> >> because there are no natural equivalencies.
> There are, of course,
> >> some common patterns for dealing with
> hierarchical and other
> >> structures in SQL, but doing an effective
> mapping requires more
> >> of an understanding of the data model so that
> the same data can
> >> be captured in both places and this is very
> difficult to
> >> automate. You might find some commercial tools
> that give you a
> >> good first pass though... ie to go from XSD to
> SQL DDL.
> >>
> >> -David
> >>
> >>
> >> On Aug 7, 2006, at 6:51 PM, Iain Fogg wrote:
> >>
> >>> Chris,
> >>>
> >>> Good question, and this probably exposes my
> ignorance of XST.
> >>> Maybe it's not the right technology. Maybe I
> need to find a tool
> >>> that can translate from XSD -> SQL. Then it
> would be
> >>> straightforward to map the relational table
> defs to the OFBiz
> >>> entity def. My small brain can't get round the
> mapping of the
> >>> hierarchical XML Schema to a relational one -
> at least not given
> >>> it's size. Maybe when I was younger :-)
> >>>
> >>> In case anyone is interested, the schema I want
> to map is the
> >>> ONIX schema (used in the book trade).
> >>>
> >>> Cheers, Iain
> >>>
> >>> Chris Howe wrote:
> >>>
> >>>> Correct me if I'm wrong, but wouldn't you need
> to know
> >>>> what the source elements are in order to make
> an XST
> >>>> to entity def? Absent knowing the structure of
> your
> >>>> source it wouldn't matter what someone else's
> XST
> >>>> looks like, it wouldn't work with yours.
> >>>>
> >>>> --- Iain Fogg <
[hidden email]> wrote:
> >>>>
> >>>>
> >>>>> That's my question...has anyone already buit
> an XST
> >>>>> to do the conversion to OFBiz Entity defs?
> >>>>>
> >>>>> BJ Freeman wrote:
> >>>>>
> >>>>>
> >>>>>> the XSD defines the layout.
> >>>>>> the XML is where the Entities definitions
> are.
> >>>>>> you can try using an XST file to convert.
> >>>>>>
> >>>>>> Iain Fogg sent the following on 8/7/2006 7:53
> AM:
> >>>>>>
> >>>>>>
> >>>>>>> I have a slightly complicated XML Schema
> (.xsd)
> >>>>>>>
> >>>>> that I would like to
> >>>>>
> >>>>>>> import into OFBiz.
> >>>>>>>
> >>>>>>> Has anyone written a tool to convert XML
> schemas
> >>>>>>>
> >>>>> into OFBiz entity
> >>>>>
> >>>>>>> definitions?
>