[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]