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] [Fwd: [xml-dev] Extract A Subset of a W3C XML Schema?]


Please see comments below. Duane, these are all things that I know you
already know - just stating them for the benefit of folks who may not.

<Quote1>
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.
</Quote1>

Absolutely - this is [our Core Components work] + [an XML
serialization]. IOW, for our Core Components work these RegistryObjects
are (initially) considered to be UML models. In the future, they will
also be XML schema fragments. UN/CEFACT ATG 2 is currently working on an
XML serialization for Core Components.

<Quote2>
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..
</Quote2>

Absolutely - this is part of our Core Components work as well. For
example, a Basic Core Component (BCC) will have a "Cardinality"
attribute (represented through one or more Slots) that describes whether
the BCC is optional, mandatory, or repetitive within an Aggregate Core
Component (ACC). We have also discussed expanding this concept to allow
for the minimum or maximum *number* of occurrences to be specified as
well.

Regarding the Party elements above - we (the CC Review Subteam) will be
prescribing use of the registry classification mechanisms, along with
the Core Components Technical Specification mechanisms of BCC/BIE. So,
to represent "Address" within a "ShipperParty" context:

- "Address" would be an Aggregate Core Component (ACC)

- "ShipperAddress" - an Aggregate Business Information Entity (ABIE) -
would be derived from the "Address" ACC, and classified by the proper
node in the proper (in this case Business Process) context category. 
<Quote3>
I would be concerned about continually adding many new features. I would 
not want the registry to become a Swiss Army Knife for integration.  
</Quote3>

Absolutely - the Core Components RIM binding (CCRIM) that we are working
on will be a very large benefit to our current architecture.

Joe

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
> >>>
> >>>
> >
> >
> 
> --
> ***************************************************
> Yellow Dragon Software - http://www.yellowdragonsoft.com
> Web Services & ebXML Messaging / Registry Downloads
> Project Team Lead - UN/CEFACT eBusiness Architecture
> Phone:   +1 (604) 738-1051 - Canada: Pacific Standard Time
> Direct:  +1 (604) 726-3329
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]