http://ofbiz.116.s1.nabble.com/XSD-schema-conversion-anyone-tp170452p170462.html
Yep, I've got the SVN from a day or two back.
- I'll have to look into those.
>
> 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?
>>>>>>>>
>>>>>>>> Cheers, Iain
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> No virus found in this outgoing message.
>>>>>> Checked by AVG Free Edition.
>>>>>> Version: 7.1.405 / Virus Database: 268.10.7/411 -
>>>>>> Release Date: 7/08/2006
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this outgoing message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date:
>>>> 7/08/2006
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date:
>> 7/08/2006
>>
>
>
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date: 7/08/2006