[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] regrep 10/28/2005: Import Comment for Consideration on WS Profile
A thought just occurred to me. Using the registry for persisting schema fragment may allow for more fine grained control over object versioning too. This is a consideration. Duane -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Friday, October 28, 2005 2:53 PM To: Monica J Martin; ebXML Regrep Subject: RE: [regrep] regrep 10/28/2005: Import Comment for Consideration on WS Profile Monica: You are talking at the schema level. Any valid XML parser that supports XML Schema must have a handler to recognize and act upon and xs:import declaration. It simply passes the URI to some other mechanism that retrieves it. If the registry TC wanted to play a part in this, the storage of schema fragments in the registry, aliased using the mechanism Farrukh and Matt came up with, would work but I am not sure it offers any distinct advantage over storing them elsewhere. Certainly as intrinsic objects, there persistence would be easier to monitor. Once the parser builds the in memory representation of the schema, the imported parts are present so there is no different to the applications using the parser output. These are really XML level issues, not WSDL, BPEL or registry ones. As long as parsers are used in implementations that support xs:import and have access to the fragments there should be no problem. Duane -----Original Message----- From: Monica J Martin [mailto:Monica.Martin@Sun.COM] Sent: Friday, October 28, 2005 2:39 PM To: ebXML Regrep Subject: [regrep] regrep 10/28/2005: Import Comment for Consideration on WS Profile Farrukh and registry experts, Here is what I found and you can assist in deciding if this is an item that needs to be addressed in the Web Services Profile for Registry. Take a WSDL that references an XML schema (.xsd) [Extend what is defined in WSDL v1.1 specification: http://www.w3.org/TR/wsdl#_example2]. I am only providing the details and then we can decide if it needs redress and if so when. In this example, the stock quote schema may itself import another schema fragment. I think you could see this for example with UBL where the import a code list from somewhere else for their own core schema. My question is if the http://example.com/stockquote/stockquote.wsdl imports the http://example.com/stockquote/stockquote.xsd, and we assume that the .xsd also has an import: What impact does this have on the Registry services if any. Is a WSDL validator set up to resolve the import of the imported schema? Or, does the import of the imported schema need to be specifically declared in the import statement in the .wsdl? The XML schema specification partially addresses this [1]. I think I indirectly brought this up because of significant discussions in WS-BPEL. There were two schools of thought: 1. Require explicit import declaration of any imported document or fragment. Case cited above. What we found in WS-BPEL that even with explicit declaration of imports to an imported document, collisions may occur at the XML schema level and conflict detection may be required in implementation. I suggested in that case an implementer's hint. [2] 2. Allow transitive imports and be silent on how this is resolved in processing, i.e. there is no explict requirement for the import of an imported document be specified in the WSDL. On a related subject, do we need to address if other element definitions of the WSDL are defined by WSDL extensibility (that uses QName linking)? Thanks. [1] Section 4 (XML Schema: http://www.w3.org/TR/xmlschema-1/#composition) * The processor succeed in locating the *schema components* <http://www.w3.org/TR/xmlschema-1/#key-component> transitively required to complete an *assessment* <http://www.w3.org/TR/xmlschema-1/#key-va> (note that components derived from *schema documents* <http://www.w3.org/TR/xmlschema-1/#key-schemaDoc> can be integrated with components obtained through other means);..... [2] http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/14974/w sbpel_issues_list.html#Issue88 (TC) http://www.oasis-open.org/committees/document.php?document_id=14974&wg_a bbrev=wsbpel (public) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]