[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Models for generating CCT and Data Type schemas
From what i could gather at today's meeting, it was decided not to use the current CCT.xsd and other Rep. Term and Data Type schemas. Instead we would create new schemas based on your understanding of the CCTS. A few weeks ago i sent this out for comment. I think it follows your earlier idea of a spreadsheet/model for data types. However, i have crafted these so using existing naming rules we get the correct CCTS Dictionary Entry Names (as near as our spreadsheet formulas allow anyway). I wonder how we would go if we took these CCT models and loaded them into EDIFIX with the assumption that they were treated as ABIEs, BBIEs and ASBIEs (as in the spreadsheet) instead of types and supplementary components? In other words, treat this spreadsheet model just like any other UBL document model. The schemas we could generate would follow the NDRs for ABIEs, BBIEs and ASBIEs - but that is a good thing. After all these things are really aggregates, components and assocations. As was discused we will end up with more elements and no attributes! But i suspect that is not a bad thing either. The more i think about this there seems no reasons to have different XSD representations for CCT, DTS and their supplementary components than for BIEs. What is more we then have a consistency between the models and the schemas - which i know you have argued for. I think if we can work this out over the next weeks or so it will be acceptable in the 1.0 release. But we will need to commit to a plan tomorrow to get NDRs approval for this. Let me know if this seems practical and achievable or if you need more information. -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
UBL-CoreComponentTypes-draft1.xls
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]