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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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


Subject: RE: [regrep-cc-review] Re: Methodology - OWL


Hello all,

I am only an observer but I would like to support Duane's position that a
standard core component serialisation format is a valid and important task
for this subcommittee.  However I'm not sure I agree that only one
interfchange format is relevant or that it needs to be too tightly coupled
to the storage model so I'm going to expose my ignorance and ask a few
questions:

1	The reason to have a serialisation format is for interoperability between
"consumers" of core component data right?  I expect that the most likely
tool that will interface with a core component repository is a UML modelling
tool.  Accordingly the repository content needs to be understood by a UML
tool.  Despite it's imperfections, XMI is the most widespread fromat for
interchange of models so a core component repository probebly ought to
support delivery of core components in XMI format. As UML2 comes into play
and OMG's MOF work becomes more widely supported, I would have thought that
model interchange formats will become more important and more consistent.

2	Not all developers of e-business standards like to use a model based
approach.  In fact many would jump straight into the XML.  The obvious
problem with that is that there are a host of different ways that the same
semantic content can be represented in XML syntax.  Nevertheless wouldn't it
be nice if I could just download the re-usable components from a repository
into my XML authoring tool?  Better still if the repository provided some
consistent naming & design rules for the XML generation (such as the good
work done by the UBL group and currently being adopted/modified by
UN/CEFACT).

3	Then again this group might define a standard serialisation format in XML
or some other syntax that is a little different to either of the above.
Probably for good reason - to address the limitations of XMI and to contain
the complete CCTS model data (which UBL serialisation would not do).  So now
there is a third (and formal standard) way of representing the core
component.

4	Unfortunately I dont have enough knowledge on OWL/RDF to comment about
it's use for core component serialisation but it is at least the foundation
for another option...

I guess what I am saying is that if I were trying to build a commercial core
component repository that was useful to todays community, I think I would
offer a few options for the syntax that the same core component can be
delivered / published.  "Do you want this standard address structure as an
XMI file for your modelling tool or as a UBL NDR compliant XSD for your XML
authoring tool or in the standard OASIS representation?"

All these formats would be delivered from the same storage model so that
storage model needs to be a superset of the requirements imposed by the
various likely interchange formats.  So I think that both the current
storage model work and interchange format work need to progress in parallel.
I also think that work on serialisation needs to recognise the practical
realities of the way in which core components will be used.

For example, can we consider that:
1	Replication of a core component between repositories
2	Publishing of new core componets (eg registering a new ABIE as a context
driven variant of an ACC)
3	Querying the library of core components for an existing component to use
in my message development
all require the same data in the interchange?  Wouldn't there be lifecycle
and ownership data in the first one that is not needed in the third one.  So
the first one might NEED the "standard" interchange format whilst the last
one would better use a UBL (or UN/CEFACT) compliant XSD?

Just some thoughts... sorry for the rambling...

regards,

Steve Capell
RedWahoo
Sydney, Australia
Tel : +61 410 437854

This email message and any accompanying attachments may contain information
that is confidential and is subject to legal privilege. If you are not the
intended recipient, do not read, use, disseminate, distribute or copy this
message or attachments. If you have received this message in error, please
notify the sender immediately, and delete this message. Any views expressed
in this message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of Red Wahoo Pty.
Ltd.

Before opening any attachments, please check them for viruses and defects.
We do not accept any liability for loss or damage which may arise from your
receipt of this e-mail.


-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Wednesday, 14 January 2004 6:47 AM
To: carlmattocks@checkmi.com
Cc: CCRev
Subject: Re: [regrep-cc-review] Re: Methodology - OWL


All:

I would propose that we use a RUP/UMM type methodological approach to
our work in this area.

1. gather stakeholder requirements, technical requirements of what is
needed in the Serialization.

2. define the serialization first.

3. work backwards based on the serialization to determine what must be
present in the storage format.  IMO - the serialization requirements
will create dependencies on the storage format.

To me,  this is the correct and logical way to approach the problem.  I
hereby volunteer to take a stab at the first draft of #1 above
(requirements for the serialization).

Duane Nickull

--
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com




To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_
workgroup.php.




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