[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Schema Assembly - revision
A couple of notes: In the second example, I used reg:idref twice by mistake. The first occurrence should have read reg:uuid. It is corrected below. Nikola has commented on the names I have used in the reg: namespace. My intention is that uuid is used when submitting a new components, and idref is a reference to components already in the registry (or being submitted at the same time). It should not be assumed that these names are the equivalent of any names in use elsewhere. We may need to change them to avoid confusion. Regards Paul -----Original Message----- From: Paul Spencer [mailto:paul.spencer@boynings.co.uk] Sent: 16 July 2004 12:04 To: Egov-Registry Subject: Schema Assembly I would like to start the discussion on assembling schemas from components. One of the requirements of the e-Gov proof of concept is to be able to assemble schema documents from components. The use case is: 1. The user discovers an artefact (element, attribute or data type) in the repository that he or she requires. This could be by searching the registry or some other means. 2. The user request delivery of this artefact. 3. The regrep returns a schema document containing this artefact and all other artefacts on which it depends. This document will contain one xs:schema element for every target namespace required. Note: this depends on the registry holding all the dependent artefacts. I don't see this as a restriction, but we might need a service to check internal consistency of the registry and it must not be possible to delete an artefact from the registry if others depend on it. It is likely that we can use the mapping between Data Element Metadata (DEM) (as defined in the ebXML Registry document "Requirements for Serializations and Storage of Core Components (CC’s) and Business Information Entities (BIE ’s) within ebXML Registry Repository facilities") and the ebRIM to achieve assembly. I attach a draft. However, this mapping is not complete yet, so I have outlined below a method based on XML Schema syntax. This syntax also has the advantage of being understood by more people, so provides a better illustration I think this could be adapted to the DEM mapping easily once it is complete. It is possible to achieve this just by using the UUID of the registry artefacts. Every artefact that depends on another will need to reference that artefact by UUID. This will ensure that the correct version is used. The first example is for a complex data type referencing multiple elements: <xs:complexType name="ct1" reg:uuid="1234-5678-901234"> <xs:sequence> <xs:element name="elem1" reg:idref="1234-5678-901235"/> <xs:element name="elem2" reg:idref="1234-5678-901236">/> </xs:sequence> </xs:complexType> The second is where the reference is to a data type: <xs:element name="elem1" reg:uuid="1234-5678-901235" type="ct2" reg:idref="1234-5678-901237"/> Notes: 1. This requires some processing when registering the artefacts. The data type ct1 cannot be registered unless the elements elem1 and elem2 are already registered. Similarly, elem1 cannot be registered unless ct2 is already registered. 2. Does the ebXML registry TC work on registering ABIEs etc cover this area? Again, thoughts welcome, especially from those who are working in this area or can demonstrate why this mechanism is too simplistic and something more complex is needed. Regards Paul Spencer Director Boynings Consulting Ltd http://www.boynings.co.uk
Solution-ebXML_Registry-CC-v0_73.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]