[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [Fwd: [xml-dev] Extract A Subset of a W3C XML Schema?]
<Quote1>
I think it would be relatively trivial to define a new object type
called "XML Fragment"
</Quote1>
As per the Core Components work, the ObjectType would be one of:
- BCC (Basic Core Component)
- ACC (Aggregate Core Component)
- BBIE (Basic Business Information Entity)
- ABIE (Aggregate Business Information Entity)
etc.
We will include in the CCRIM a mechanism for the registry to signify the
type of content - i.e. UML, XML, etc.
<Quote2>
Bidirectional associations could then be used to associate the fragments
("Contains") & ("PartOf").
</Quote2>
Absolutely - also covered in the CCRIM work. For example, we will have
"Contains" associations from an ACC to its comprising BCCs.
<Quote3>
I think registry already has the capability to do this sort of thing.
</Quote3>
Yes - and that is what we are leveraging as part of the CCRIM work.
<Quote4>
Must we place every use case in the specification?
</Quote4>
You're going to see *plenty* of use cases in our CCRIM Technical Note,
due out in the Fall.
<Quote5>
Maybe a best practice doc is needed.
</Quote5>
You might consider the CCRIM Technical Note to be such a best practice
doc. Stay tuned...
Joe
Matthew MacKenzie wrote:
>
> I think it would be relatively trivial to define a new object type
> called "XML Fragment", then use a simple tool which merely took a
> schema, made a copy of the enclosing <schema /> element, inserted that
> to the registry, then one by one added all other global elements top the
> registry. Bidirectional associations could then be used to associate
> the fragments ("Contains") & ("PartOf").
>
> I think registry already has the capability to do this sort of thing.
> Must we place every use case in the specification? Maybe a best
> practice doc is needed.
>
> -Matt
>
> Duane Nickull wrote:
>
> > Farrukh/Joseph:
> >
> > I would believe the correct approach would be to do one of the follwoing:
> >
> > 1. Place only schema fragments into the registry in the first place.
> > This maximizes re-use of data elements amoung multiple schemas. Each
> > schema fragment is a separate registry object and can be individually
> > retrieved, then aggregated outside of the registry into a schema.
> > This is the CC and BIE approach and I was about to put UBL into the
> > Registry in this manner. Each Daa Element is a registry obejct.
> >
> > Problems occur with respect to cardinality rules and context. Is
> > "Address" the same within the context of a mapping source if it occurs
> > within a heirarchic context of //PO/ShipperParty than when it occurs
> > in //PO/BuyerParty? I think not..
> >
> > 2. Allow participants to retrieve the entire schema then work on it
> > externally. It is easy towrite code to do this outsideofthe registry.
> >
> > I would be concerned about continually adding many new features. I
> > would not want the registry to become a Swiss Army Knife for
> > integration. It has a scope in the architecture as a
> > registry/repository to support other applications/processes.
> >
> > Duane
> >
> >
> > Farrukh Najmi wrote:
> >
> >> Chiusano Joseph wrote:
> >>
> >>> Forwarding from XML-DEV - the original question was:
> >>>
> >>> <Quote>
> >>> I have been asked what tools can extract a part of a schema. The
> >>> overall schema is large, complex, and imports five or six other schemas
> >>> into several target namespaces. The individual involved wants to
> >>> create
> >>> a smaller subset that contains everything that one project needs, for
> >>> the purposes of instruction and training.
> >>> </Quote>
> >>>
> >>> Please see my response below, discussing what our Registry will be able
> >>> to do for him in the future.
> >>>
> >> This is good Joe.
> >>
> >> I too have been thinking about this concept under the title of
> >> supporting "Dynamic Content Assembly" of any type of content within
> >> the registry with focus on XML content of course. David Webber and I
> >> plan to speak on this concept today or tomorrow to discuss this in
> >> context of his experience in OASIS CAM. This idea of server side
> >> "Dynamic Content Assembly" is an essential feature for Enterprise
> >> Content Management (ECM). I think it is much more interesting to
> >> support this as a capability within the registry than as a feature
> >> outside the registry within registry client.
> >>
> >> Maybe we can add this to next week agenda for discussion? Thanks.
> >>
> >>>
> >>> Joe
> >>>
> >>>
> >>> ------------------------------------------------------------------------
> >>>
> >>>
> >>> Subject:
> >>> Re: [xml-dev] Extract A Subset of a W3C XML Schema?
> >>> From:
> >>> Joseph Chiusano <Chiusano_Joseph@bah.com>
> >>> Date:
> >>> Thu, 31 Jul 2003 08:57:09 -0400
> >>> To:
> >>> "Thomas B. Passin" <tpassin@comcast.net>
> >>>
> >>>
> >>> Tom,
> >>>
> >>> This won't help you in the immediate present (don't you like it when a
> >>> response starts like that?;) but:
> >>>
> >>> In the future, my vision is that the OASIS/ebXML Registry will allow
> >>> one
> >>> to do exactly this. The Registry architecture does not yet (explicitly)
> >>> allow for the registration of "fine-grained" XML artifacts such as
> >>> elements/attributes/datatypes/namespace identifiers, but I am
> >>> working to
> >>> ensure that in the future it will (and am confident that we will reach
> >>> this goal within the next year).
> >>> So, referencing your example, my vision is that one would be able to
> >>> query the Registry for all elements/attributes/datatypes that belong to
> >>> targetNamespace XYZ, and select a subset of those elements to be
> >>> included in a new schema that is then assembled using that subset.
> >>>
> >>> Kind Regards,
> >>> Joe Chiusano
> >>> Booz | Allen | Hamilton
> >>> Member, OASIS/ebXML Registry TC
> >>>
> >>> "Thomas B. Passin" wrote:
> >>>
> >>>
> >>>> I have been asked what tools can extract a part of a schema. The
> >>>> overall
> >>>> schema is large, complex, and imports five or six other schemas
> >>>> into several
> >>>> target namespaces. The individual involved wants to create a
> >>>> smaller subset
> >>>> that contains everything that one project needs, for the purposes of
> >>>> instruction and training.
> >>>>
> >>>> The problem is how to get all the necessary pieces so that nothing
> >>>> is left
> >>>> out that is required for the schema to work. XML Spy can be
> >>>> helpful with
> >>>> its graphics, but there is no link from the graphics view to the
> >>>> text view,
> >>>> so it is hard to find the pictured piece of the XML for copying.
> >>>> You can
> >>>> do some degree of copying and pasting the graphics view blocks between
> >>>> schemas, but of course you have to keep track yourself of the bits
> >>>> you have
> >>>> already transferred. Also it is hard to be sure you have gotten
> >>>> everything
> >>>> you need.
> >>>>
> >>>> Does anyone know of such a tool? If not, any suggestions based on
> >>>> actual
> >>>> experience in doing this kind of task? It seems to me that finding
> >>>> all the
> >>>> dependencies within the schema and its imports would be the hardest
> >>>> part.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Tom P
> >>>>
> >>>> -----------------------------------------------------------------
> >>>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> >>>> initiative of OASIS <http://www.oasis-open.org>
> >>>>
> >>>> The list archives are at http://lists.xml.org/archives/xml-dev/
> >>>>
> >>>> To subscribe or unsubscribe from this list use the subscription
> >>>> manager: <http://lists.xml.org/ob/adm.pl>
> >>>>
> >>>> You may leave a Technical Committee at any time by visiting
> >>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php
> >>>>
> >>>>
> >>
> >>
> >
>
> --
> Matthew MacKenzie
> Yellow Dragon Software Corporation
> http://www.yellowdragonsoft.com/
> m: +1 506.869.0175
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]