- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Thu, 03 Jan 2002 13:23:49 -0500
- To: Marc Hadley <marc.hadley@sun.com>
- CC: Jacek Kopecky <jacek@systinet.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, noah_mendelsohn@us.ibm.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
+1 This was what I was proposing at the last f2f, that the encoding should be restricted to ID/IDREF within the envelope (XML) document. Any external references are (application) data (e.g. an anyURI type element information item). Cheers, Chris Marc Hadley wrote: > Jacek Kopecky wrote: > >> >> My major position is that we should disallow external references >> altogether for they bring so much trouble and are inconsistent >> with the usual RPC approach to data. >> The two major problems are >> 1) missing data and >> 2) typing of the external data. >> The one major gain is SOAP w/Attachments. Attachments can be >> implemented in a different way very easily: >> >> <linkToAttachment xsi:type="att:AttachmentReference"> >> cid:... >> </linkToAttachment> >> >> And this would be quite the same as the way Maps etc. are being >> represented now. Who thinks attachments are more important and >> used more widely than maps? >> If we get rid of external references, the missing data problem >> will stay, but then it would IMHO be apparent that such case is a >> fault. >> > > +1 on Jacek's position. Disallowing external references as graph edges > (e.g. by use of IDREF instead of a general link for edges) within the > encoding is IMO a very worthwhile simplification. Just to reiterate > Jacek's point: this doesn't mean that external links can't be carried as > values as shown above, it just means that such links are considered to > be application data rather than being something that the SOAP processor > has to deal with as part of encoding [de]serialisation. > > Marc. >
Received on Thursday, 3 January 2002 13:24:53 UTC