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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] ebXML Registry "Granularity"


I wrote a sentence that made no sense.

<Was>
I think that tackling both efforts done concurrently, as one can learn
from the other.
</Was>

<ShouldBe>
I think that tackling both efforts should be done concurrently, as one
can learn from the other.
</ShouldBe>

Chiusano Joseph wrote:
> 
> Thanks Farrukh. Over the next few weeks I plan to think about possible
> approaches. Then, shortly after we kick off the Core Components
> Serialization work I think we can begin tackling this in tandem, as
> there will be a certain amount of overlap. I think that tackling both
> efforts done concurrently, as one can learn from the other.
> 
> Joe
> 
> Farrukh Najmi wrote:
> >
> > Joe +1 on the need to address fine grained sub-document level content.
> > It is already on teh list for V4 but I can see the need to at least do a
> > TN right away on it. I would be glad to work with you on this.
> >
> > Chiusano Joseph wrote:
> >
> > >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
> > >
> >
> > --
> > Farrukh
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]