[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Re: ISSUE 8: SCDL artifact resolution underspecified (schemaadjustments for uniqueness?)
Thanks Dale, that helps a lot. My reasoning is that QNames seem easier to work with than URIs when you're developing artifacts without tools, and they seem less fragile. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Moberg Dale" <dmoberg@axway.co m> To David Booz/Poughkeepsie/IBM@IBMUS, 02/11/2008 05:47 <sca-assembly@lists.oasis-open.org> PM cc Subject RE: [sca-assembly] Re: ISSUE 8: SCDL artifact resolution underspecified (schema adjustments for uniqueness?) 1. If the intent is that the names of composites be unique within a targetNamespace, that requirement would be documented. 2. I guess you are wondering whether you could thereby leverage a validity check on a file, to check on that constraint. I doubt that tools normally enforce checking over multiple files, and as you point out, just doing some kind of include over files where composite is the root element won't yield a valid rooted tree anyhow. 3. I also am pointing out that qnames are usually used where some guarantee of uniqueness of referent is available. That may tend to count against the wisdom of using qnames for reference in scdl contributions, given that you have no way to check on that assumption. URI-references, given unique URLs for the members of the contribution, might be a better bet. You could use standard fragments picking out referents by their ID value and be done with it. I have had some difficulty understanding why you are bothering with qname anyway, because it doesn't seem like a clearly applicable device. Your remark makes me wonder what the attraction really was? Dale Moberg I didn't follow how this helps for composites, since they are all in unique XML instance documents. It would help within a single sca definitions file (for bindingTypes, intents, etc). But even in this case, we need to worry about the presence of multiple sca definitions documents in the same contribution. I suppose one could merge all the sca definitions documents (that are in the same namespace) into one logical document and then run schema validation over the logical document. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Moberg Dale" <dmoberg@axway.co m> To "Michael Rowley" <mrowley@bea.com>, 02/11/2008 12:25 David Booz/Poughkeepsie/IBM@IBMUS, PM <sca-assembly@lists.oasis-open.org> cc Subject ISSUE 8: SCDL artifact resolution underspecified (schema adjustments for uniqueness?) Michael Rowley states I believe that SCA definitions (composites, binding types, intents, etc) should all be unique within a single "contribution context", by which I mean a contribution and the exported definitions of all of its dependent contributions. If others agree, I'll add that text. Dale Moberg>> WSDL and also schema enforce uniqueness for named things that they intend to reference by qnames. For example, WSDL 1.1 uses the key constraint * (unique) the Identity-constraint definition asserts uniqueness, with respect to the content identified by [selector], of the tuples resulting from evaluation of the [fields]: XPath expression(s). * (key) the Identity-constraint definition asserts uniqueness as for unique. key further asserts that all selected content actually has such tuples. as follows: <xs:element name="definitions" type="wsdl:tDefinitions" > <xs:key name="message" > <xs:selector xpath="wsdl:message" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="portType" > <xs:selector xpath="wsdl:portType" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="binding" > <xs:selector xpath="wsdl:binding" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="service" > <xs:selector xpath="wsdl:service" /> <xs:field xpath="@name" /> </xs:key> <xs:key name="import"> > <xs:selector xpath="wsdl:import" /> <xs:field xpath="@namespace" /> </xs:key> </xs:element> While this will only enforce uniqueness of named component, er thing, within the "targetNamespace", it might be useful to add the appropriate constraints to the scdl schemas, especially if you add in the Assembly specification, a requirement for uniqueness of named scdl things that are to be referenced by qnames. For XML Schema and WSDL definitions that are found by QNames, I think they can be ambiguous, but we can use the standard __Location attributes. I think that should cover the practical issues with existing badly behaved artifacts. I don't know what to do about Java. I'm inclined to continue to say very little. We currently say that "the installed contribution provides the context" in which fully qualified classnames are resolved, but it doesn't say _how_ they are resolved (in fact it says there may be multiple ways). I think we should continue along those lines. --------------------------------------------------------------------- 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]