RE: Media type encoding parameter?

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 10:28:01 UTC