OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov-registry message

[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]