RE: [regrep] ebXML Registry "Granularity"

["Peter Kacandes" <pkacande@adobe.com>]

I would agree with Joe that this is an important thing to do.

We at Adobe are very interested in this as it relates to our PDF/XML form
design efforts.

Gov't folks are telling us that they want to be able to register the
elements, schemas etc. and they have those be used in the design of the
PDF/XML forms. The forms themselves would also then be registered. Users
would then search the registry to find the appropriate form, download it,
fill it out, and register the completed form back where the agency would
then extract the XML data from the form.

hth

cheers

pk


-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Thursday, May 15, 2003 9:48 AM
To: regrep@lists.oasis-open.org
Subject: [regrep] ebXML Registry "Granularity"


Team,

This week I participated in a series of federal XML meetings in which
the OASIS/ebXML Registry standard was mentioned as a candidate for
various potential roles within multiple federal government initiatives.

That's great news.

In most if not all of these references, there is a *very strongly*
expressed requirement for granular registration - that is, registration
of elements, attributes, and datatypes - as well as XML namespace
support. There has been a very big push within the federal government in
the past several years for component-based architectures, both from a
software module standpoint as well as a data standpoint.

I know that if an implementer chose to, they could include such
functionality in their ebXML Registry product, given the abstract nature
of our information model. But the reality is that people read our
specifications and they don't explicitly glean from the specs that the
ebXML Registry standard can accomodate granular registration and
maintenance - so they close the specs and potentially move on to other
possible solutions (solutions which do exist in the federal space and do
allow such granular registration and maintenance, as well as namespace
support).

That's not-so-great news.

What I would like to propose is that, in no greater than 3 months, we
make a big technical and marketing push to educate the world as to the
potential of granular registration and maintenance for an ebXML
Registry. I think a great first step would be the creation of a series
of Technical Notes that address (1) how to register and maintain
elements, attributes and datatypes in an ebXML Registry and (2) how to
register and maintain namespaces, and associate elements, attributes,
and datatypes with their namespaces.

Then, we can combine this capability with CAM, and allow registry users
to assemble schemas using registered artifacts such as namespaces,
elements, attributes, and datatypes.

Is anyone with me on this challenge?

Kind Regards,
Joe