Re: [egov-registry] Schema Assembly - revision

["Carl Mattocks" <carlmattocks@checkmi.com>]

Paul:

Agreed - the XML Schema syntax should appeal to target audience,.

The pre-processing steps (for elements) you describe in the notes are
necessary.

It has been acknowledged that - the need to pre-register 'referenceable
components' (including data types, business categories) is also a
dependency when registering Core Components such as ABIEs .

I think the most valuable output of our work will be the sequence of
(registration) steps that MUST and SHOULD be taken.

carl


<quote who="Paul Spencer">
> 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.


-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi