RE: proposed resolution to issues #159 and #166 - encodingStyle

 Andrew,
 thanks for this clarificaion. I thought the reasons were exactly
such and I thought the spec was nearly clear enough on this
intent.
 On the other hand if we wanted this, we might have to specify
exactly how B and A MUST be related in order for the encodingStyle
"B A" to be a valid combination. I have a version of such text:
 "Any data serialized according to B MUST be a valid serialization
of the data according to A while it may not be true the other way
around."

 I don't think this is hard to implement, it's just that I haven't
seen any actual use of this. The only scenario I can imagine comes
from the word "restriction" or "specialization" in the text about
encodingStyle.
 The scenario is that a constrained implementation would like to
use some trimmed version of an encoding while still being able to
communicate to (not with) unrestricted implementations that don't
know the trimmed version.
 I've used the word "to" as opposed to "with" in the previous
sentence quite on purpose. It's because the unrestricted
implementation could not communicate stuff back because of the use
of the unrestricted version which apparently the constrained
implementation cannot handle.
 This can actually be used in the real world but it's such an
unlikely scenario...

 And I'm not sure my paragraph would be sufficient to describe
_and_ explain what the multiple encodingStyle URIs mean.

 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 20 Nov 2001, Andrew Layman wrote:

 > Perhaps I can add some insight into the original motivation.
 >
 > The thought was that one might have a message encoded according to the
 > section 5 rules.  Call this rule A.  One might also have, while
 > consistent with the section 5 rules, applied some additional rules, such
 > as avoiding forward references.  Call this rule B.
 >
 > It was thought useful to indicate both, so that an application which
 > understands only rule A could process the message correctly, while an
 > application that understands rules A and B could take advantage of the
 > extra information to process the message more efficiently.
 >
 > The value of the encodingStyle attribute would be "B A".
 >
 > -----Original Message-----
 > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > Sent: Tuesday, November 20, 2001 4:14 AM
 > To: xml-dist-app@w3.org
 > Subject: proposed resolution to issues #159 and #166 - encodingStyle
 >
 >  Hi all. 8-)
 >  The ETF proposes the following resolution to the issues 159 and
 > 166, both dealing with the type of the encodingStyle attribute
 > being a list of URIs identifying encoding styles in the order
 > from the most specific to the least specific.
 >
 >  The proposal is to make the attribute be of type anyURI and
 > indicate a single style.
 >
 >  Motivation:
 >  For the discussion that resulted in this you can see [1] and the
 > resulting thread. The participants in the thread generally seemed
 > to agree that the presented resolution is the way to go,
 > especially since nobody was able to bring up a valid scenario for
 > using more than a single value of the attribute.
 >  The two examples brought up in the thread both were about
 > multiple _different_ encodings in one message which is handled by
 > the encodingStyle attribute scoping.
 >  Also, no real-world usage of multiple values in one
 > encodingStyle attribute was demonstrated, nor conceived by the
 > participants in the thread.
 >  If we wanted to keep the status quo, we would need to specify
 > what "most specific to least specific" means with respect to
 > encoding styles and this would unnecessarily complicate the spec.
 >  Best regards
 >
 >                    Jacek Kopecky
 >
 >                    Senior Architect, Systinet (formerly Idoox)
 >                    http://www.systinet.com/
 >
 > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0330.html
 >
 >
 >

Received on Wednesday, 21 November 2001 17:28:01 UTC