W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: Issue #170: "Referencing Data missing from the message"

From: Christopher Ferris <chris.ferris@sun.com>
Date: Thu, 03 Jan 2002 13:23:49 -0500
Message-ID: <3C34A1B5.1010402@sun.com>
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

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



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:45 UTC