RE: Proposal for issue 306: Is use of Appendix A optional?

Jacek,

Henrik originally suggested that the text go in 2.1.1, I disagreed with him, because the Data Model says NOTHING about an encoding. And Appendix B ( ne้ A )really is an encoding.

Gudge

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com] 
> Sent: 04 September 2002 20:33
> To: Henrik Frystyk Nielsen
> Cc: xml-dist-app@w3.org; Martin Gudgin
> Subject: Re: Proposal for issue 306: Is use of Appendix A optional?
> 
> 
>  Henrik,
>  I disagree that the reference to the (currently) Appendix B 
> can be moved to SOAP Encoding. In SOAP Data Model an edge 
> label is defined as having the type of XML Schema QName, so 
> no remapping is necessary in SOAP Encoding because nothing 
> would ever be remapped. So the reference should probably move 
> to SOAP Data Model, section 2.1.1 Edge Labels.  As for the 
> other part of the issue, I think this MUST can be hard to 
> enforce and not following it doesn't break interoperability 
> (of course the names must be QNames, but assuming they are, 
> it doesn't matter how the implementation mapped its names to 
> QNames), so I prefer MAY here. The appendix is very useful 
> for implementations that need two-way mapping or they just 
> don't have a mapping yet.  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> On Wed, 2002-09-04 at 21:16, Henrik Frystyk Nielsen wrote:
> > 
> > 
> > Issue 306 states that
> > 
> > "It is unclear in the RPC Representation whether the links to  
> > Appendix A are a MUST (an identifier MUST be mapped to an XML  name 
> > using Appendix A's algorithm) or a MAY (for a possible  mapping 
> > algorithm see Appendix A)."
> > 
> > The reference to "Appendix A" should now be read as 
> "Appendix B" [2] 
> > as we have inserted the media type registration as appendix A. 
> > Appendix B defines a mapping for converting application 
> defined names 
> > to XML names. It is only referenced from part 2 section 4.2 
> "RPC and 
> > SOAP Body" [3].
> > 
> > I think there are two parts of this problem:
> > 
> > 1) Is the mapping required (MUST) or not (MAY)?
> > 
> > 2) Is the mapping useful in other places than section 4.2?
> > 
> > There is no doubt that Appendix B is normative meaning that 
> it counts 
> > as "specification" and not "example" or otherwise. My 
> feeling is that 
> > *if* one uses names in the RPC convention that cannot be 
> represented 
> > directly in XML then one MUST use Appendix B.
> > 
> > However, given that the RPC convention uses the SOAP encoding, it 
> > seems strange to me to have the reference to Appendix B in the RPC 
> > convention and not as part of the SOAP encoding. I would therefore 
> > suggest that the reference to appendix B is moved to section  3.1.3 
> > "Encoding compound values" [4] and not just in section 4.2 "RPC and 
> > SOAP Body" [3].
> > 
> > The proposal for closing issue 306 is therefore:
> > 
> > We clarify that the SOAP encoding requires use of the 
> mapping defined 
> > in appendix B for encoding names that can not directly be 
> expressed in 
> > XML. This requirement will be expressed in section 3.1.3 "Encoding 
> > compound values" [4] something like this:
> > 
> > "Note: An edge label is an XML Schema Qualified Name (see 
> [XML Schema 
> > Part2]). Names that cannot be represented directly as XML Schema 
> > Qualified Names MUST use the mapping defined in Appendix B. 
> "Mapping 
> > Application Defined Names to XML Names"."
> > 
> > The references in section 4.2 will be removed.
> > 
> > Comments?
> > 
> > Henrik Frystyk Nielsen
> > mailto:henrikn@microsoft.com
> > 
> > [1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x306
> > [2] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml#namemap
> > [3] 
> > http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml#rpcsoapbdy
> > [4] 
> http://www.w3.org/2000/xp/Group/2/06/LC/soap12> -part2.xml#complexenc
> 
> 
>

Received on Wednesday, 4 September 2002 15:35:00 UTC