[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Creating a new document... where to start?
I believe the "customization methodology" paper talks mostly about a different area that falls more towards "contextualization", which means to provide a context on which to parse a given instance document against a given schema. It inherently assumes a rather intelligent schema parser that is capable of peering into the 8 context variable elements stored inside <xsd:annotation> of the instance document. Depending on the data stored in those variables, the intelligent schema parser behaves differently, and may even initiate a change of schema against which to parse the same instance. The various discussion in the paper about 'redefine' and schema restrictions are just mechanisms to realize the above. It's probably a seeding paper to start the discussion of a complicated dynamic parsing methodology. We could probably hear more about the details subsequently. Creating a new document schema by customizing the ABIEs doesn't have to be that complicated, nor needing to have a dynamic aspect to it (i.e. having to depend on the data variables in the instance document). No fallback parsing, no dynamic behavior, and no special intelligent schema parser are expected. One of the more important challenges is certainly to convey standardized meanings between the trading partners, so that business can expand and not having to revisit fundamental semantics all the time. But this has exactly been done by UBL's collection of ABIEs! Fundamentally, tweaking any aspect of UBL's published schema will amount to customizing, even changing the cardinality of an element (say from 0..1 to 0..0). One might not see the effect until a new trading partner who uses a standard schema (with cardinality 0..1 of the example element) and actually instantiates that element and sends that instance (with the example element) to you. So I think the atomic model of ABIEs still serves us well in this aspect. Find the semantically closest matching ABIEs, and assemble them together. Any unused fields should be flagged outside the ABIE's schema and not changed within the ABIE's schema. There's a lot more to be said but it'll make the mail too long. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ On Fri, 18 Jun 2004, Stephen Green wrote: >>Steven and all ubl-dev folk, >> >> >>I'm actually trying to find a clear path in this area too. >> >>I've been trying to 'customize' the reusable ABIEs >>using the 'customization methodology' (as described in >>the paper in the UBL package by Eduardo Gutentag >>and Arofan Gregory et al) so as to define Schemas for >>simpler documents of order and invoice which would >>also be valid documents by the original order and invoice >>Schemas. >> >>I end up with, say, an order looking like the first Schema >>at the end of this message and the Common Aggregate >>Components Schema like that at the bottom below. >> >>Notice that there are many BBIEs and ASBIEs in the common >>Schema with *both* min occurs and max occurs equal to zero >>e.g. <xsd:element ref="cbc:District" minOccurs="0" maxOccurs="0"> >>and that I've imported the original Common Aggregates Schema >>and given my schema a new version number. >> >>... >> >>All the best >> >>Stephen Green >> >>Here is an order Schema >> >><xsd:schema [... namespaces, ... imports ] version="0:1-sdg"> >>... >>and so on and so on >>... >></xsd:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]