Re: Media type encoding parameter?

+1

Williams, Stuart wrote:

> Mark, Jacek,
> 
> I guess that a (small) concern I have with some of the direction this is
> taking is that it introduces the potential for the metadata to be
> inconsistent with the actual message content, this creates new failure cases
> and potentially some need to consider how such inconsistencies should be
> handled and so-forth. 
> 
> I think if we create a means to create inconsistency between say some
> fine-grain message type expressed in a content-type header and the actual
> type of the message content, there will be folks with either curious or
> malicious intent that 'experiment' with being inconsistent.
> 
> The more stuff that leaks out of the message headers the more potential to
> be inconsistent...
> 
> I think we need to keep this stuff to the bare essentials and largely with
> the status of a hint, ie. the presense of inconsistency the message content
> is king.
> 
> Just my 0.02p.
> 
> Best regards
> 
> Stuart
> 
> 
>>-----Original Message-----
>>From: Mark Baker [mailto:distobj@acm.org]
>>Sent: 03 January 2002 13:40
>>To: jacek@systinet.com
>>Cc: xml-dist-app@w3.org
>>Subject: Re: Media type encoding parameter?
>>
>>
>>Jacek,
>>
>>
>>> > That isn't a requirement of a media type parameter.  
>>>
>>"charset" is also
>>
>>> > not used to dispatch.
>>>
>>> I'm not sure here, but I think the charset may not be indicated
>>>by the XML document itself and it must be known somehow. Anyway,
>>>the charset (in the extreme) is necessary before even parsing the
>>>text because in a strange charset the angle brackets can be
>>>something completely other than ASCII angle bracket
>>>representation. So without this knowledge you wouldn't even be
>>>able to read the XML.
>>>
>>Not exactly true, since there are ways to recognize XML as a data
>>stream without metadata (see RFC 3023 and the XML Rec, sec 4.4.3).
>>But my point in bringing it up was to show that it isn't required
>>that a parameter be used to make dispatching decisions, as you
>>stated.
>>
>>
>>> On the other hand namespaces or any other XML information from
>>>the document is always in the document.
>>>
>>True, but being available in the body does not preclude it from
>>being made available elsewhere.  Sometimes there are practical
>>considerations.
>>
>>
>>> If I take your words literally, you again want every bit of the
>>>message outside of the envelope, for generally every bit of the
>>>message can affect success or failure of processing.
>>>
>>That doesn't follow.  Not every bit of a SOAP message can affect the
>>processing of a message.  For example, a SOAP processor isn't required
>>to look at the bits in the body block.
>>
>>The only bits I'm interested in *considering* to be copied outside the
>>envelope are the ones that might cause faults.  See part 1 sec 4.4.5
>>for that list.
>>
>>
>>> So I think you meant to say "...any reasonable and prudent
>>>information that impacts..."
>>>
>>I thought I was saying that, but ok.
>>
>>
>>>and now we could argue about what's
>>>reasonable and prudent outside of the envelope. I say, for SOAP,
>>>nuffin'. If we were talking about a parameter of a type
>>>application/xml, that would be different, for the root namespace
>>>could be useful indeed.
>>>
>>How would that be different?
>>
>>
>>>Even though, AFAIK, encodingStyle is commonly used on the body
>>>and there is usually only one, I dislike the trouble we'd get
>>>into in trying to handle the unusual and uncommon cases. Once
>>>there is only one something, like the root namespace of an XML
>>>document, I'm OK with optionally indicating it outside of the
>>>envelope, too,
>>>
>>There can be more than one namespace too.  We could refer to the
>>"root encodingStyle", and treat is we would the "root namespace".
>>I don't see the difference between the two.
>>
>>
>>>but again, for a generic MIME type, not for
>>>application/soap[+xml].
>>>
>>MB
>>-- 
>>Mark Baker, Chief Science Officer, Planetfred, Inc.
>>Ottawa, Ontario, CANADA.      mbaker@planetfred.com
>>http://www.markbaker.ca   http://www.planetfred.com
>>
>>
>

Received on Thursday, 3 January 2002 11:33:21 UTC