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] GCN:"Would a governmentwide XML schema registry cut duplication?"


Thanks Farrukh. I was actually referring to "more native" than we
currently do. That is, folks pick up our specs, look for references to
registering these items, and they do not find a reference - they then
come to the conclusion that the registry cannot support these
requirements. I know that it can, if an implementer wanted to include
this support - but I am certain that we need to give one the ability to
do the following:

(1) Search for all XML elements that belong to namespace XYZ
(2) Register an XML attribute and associate it in the registry with
specific XML elements
(3) Discover all complex datatypes that contain elements that were
submitted by organization YYY
etc.

A standard mechanism for this in our specs - or a Technical Note - would
help ensure that vendors implement this functionality in a standard way.
Frankly, this void is IMHO one of the things that has inhibited the
existence of an US federal XML registry (or series of registries). I'm
basing this not only on my opinion, but on the opinions of folks in the
federal space that I have heard over and over for years now.

Thanks so much,
Joe

Farrukh Najmi wrote:
> 
> Chiusano Joseph wrote:
> 
> >Just released: Government Computer News (GCN) feature on XML registries,
> >featuring Owen Ambur (XML.gov Co-Chair) and Marion Royal of GSA.
> >
> >Title: "Would a governmentwide XML schema registry cut duplication?"
> >
> >Quote: "It is far harder than it should be for folks to discover and
> >reuse data elements, not to mention actual instances of data," said
> >Ambur, a systems analyst for the Fish and Wildlife Service. "They are
> >often left with no practical choice but to reinvent the data elements
> >they need."
> >
> >Of course, this can only be fully realized when the OASIS/ebXML Registry
> >standard has *native, standard* support for registration, maintenance,
> >and discovery of fine-grained artifacts
> >(elements/attributes/datatypes/namespace identifiers), along with a
> >*standard mechanism* to assemble these into schemas. :)
> >
> >
> Thanks for sharing this Joe.
> 
> The ebXML Registry standard already supports:
> 
> "
> *native, standard* support for registration, maintenance,
> and discovery of fine-grained artifacts
> (elements/attributes/datatypes/namespace identifiers)
> "
> 
> Note that we have had above abilities since version 1.0 of the ebXML
> Registry.
> 
> What we do not yet have is the
> 
> "*standard mechanism* to assemble these into schemas"
> 
> I also want to point out that the "*standard mechanism* to assemble
> these into schemas"
> is not and has never been part of our charter. We view this as an
> application that is a client
> of the ebXML Registry. We are willing to help anyone who wishes to
> develop such a client.
> 
> Please let me know if I misunderstand the issue and do what you can to
> correct any accidental misleading
> perception. Thanks.
> 
> --
> Regards,
> Farrukh
> 
> --------------------------------------------------------
> Going to Java One 2004 June 28 - July 1?
> 
> http://java.sun.com/javaone/
> 
> Come see the newly released freebXML Registry 3.0
> at pod 1220 in the Java One Pavilion:
> 
> http://ebxmlrr.sourceforge.net
> http://ebxmlrr.sourceforge.net/presentations/freebXMLRegistryBrochure.pdf
> http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/04-02-02.pdf
> 
> --------------------------------------------------------
> 
> 

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton


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