- From: Jacek Kopecky <jacek@systinet.com>
- Date: Wed, 12 Dec 2001 17:24:34 +0100 (CET)
- To: Jean-Jacques Moreau <moreau@crf.canon.fr>
- cc: "John J. Barton" <John_Barton@hpl.hp.com>, xml-dist-app <xml-dist-app@w3.org>
Jean-Jacques, can you show me a scenario where you need to know in SOAP-Encoding-encoded data the type before trying to dereference? Anyway, the "other means" can include guessing from the URL. 8-) I'm strongly against saying "the application decides whether or not to dereference a particular SOAP Encoding href". Best regards, Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Wed, 12 Dec 2001, Jean-Jacques Moreau wrote: > Jacek, > > I am not so much concerned by the local href, but by the external one, and would > prefer not to have to derefence the (external) href to find out the type of the > resource at the other end. > > Jean-Jacques. > > Jacek Kopecky wrote: > > > Jean-Jacques, > > again, what would you do with the following? > > <a id="1" xsi:type="xsd:string" >42</a> > > <b href="#1" enc:hrefType="xsd:ing"/> > > I'm opposed to enc:hrefType attribute because it puts typing > > information on the accessor, whereas SOAP Encoding types values, > > not accessors. > > > > I believe the current Encoding tries to comply to a > > contradictory set of requirements using one mechanism: > > > > 1) being able to share data and therefore enabling circular > > graph structures, > > 2) being able to point to anything out there, > > 3) typing all values. > > > > We can remove the requirement 2) or 3), the former IMO results > > in a cleaner and nicer beast. Or we can try other paths, like > > adding other linking mechanism (like gref which was I think > > proposed at the f2f), or like the following one that I just > > thought about: > > "The href attribute can in fact point to anything at all and > > it's the pointee's responsibility to provide it's type > > information. (In case of XML, type can be gotten from a schema or > > from the xsi:type attribute inf. item, in other cases by other > > means.)" > > IMO this simple text, if present somewhere in the Encoding spec, > > would close issue 168 (relying on third-party specifications or > > implementors' practices for the "other cases" as SOAP does > > already in places like ordering of header processing, for > > example). > > > > Jacek Kopecky > > > > Senior Architect, Systinet (formerly Idoox) > > http://www.systinet.com/ > > > > On Wed, 12 Dec 2001, Jean-Jacques Moreau wrote: > > > > > Congratulations for finding out what the "S" now stands for in "SOAP"! :) > > > > > > On a more serious note, I think Jacek was ruling this out in his proposal [1] > > > (ante-penultimate paragraph), the reason being it is "too complicated". > > > > > > Personnally, I would prefer us to say instead that "the type of the referenced > > > entity MAY be indicated by the enc:hrefType attribute". > > > > > > Jean-Jacques. > > > > > > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0129.html > > > > > > > > > "John J. Barton" wrote: > > > > > > > At 07:48 PM 12/11/2001 -0500, Mark Baker wrote: > > > > >An enthusiastic +1 > > > > > > > > > > > I agree and on a slightly more serious note, I would from a general Web > > > > > > architecture point of view suggest that we not go down this particular > > > > > > slippery slope. > > > > > > > > Somewhere in this thread I lost with whether or not > > > > my SOAP application would be able to predict the > > > > datatype of an external reference without accessing > > > > the resource. I gather that the answer is "not through > > > > SOAP". I can guess from the URL. I can make an extra > > > > element. But the system doesn't say. Its Smalltalk, > > > > not Pascal. (I'm ok with that, just unclear). > > > > > > > > ______________________________________________________ > > > > John J. Barton email: John_Barton@hpl.hp.com > > > > http://www.hpl.hp.com/personal/John_Barton/index.htm > > > > MS 1U-17 Hewlett-Packard Labs > > > > 1501 Page Mill Road phone: (650)-236-2888 > > > > Palo Alto CA 94304-1126 FAX: (650)-857-5100 > > > >
Received on Wednesday, 12 December 2001 11:24:42 UTC