Next in thread →
Next in month →
RE: [wss] xml:id proposal
Paul, (1) It is described in the document (http://www.w3.org/TR/xml-id/) in section "C Impact on Canonicalization (Non-Normative)" these issues impact the usage of Inclusive C14N (3) I agree with your update to change the MUST to a MAY, but Item #1 effects senders, I did not see where Frederick covered senders, so this would be new text that needs to be added. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 "Paul Cotton" <> "Paul Cotton" <> 09/04/2005 11:33 AM To Anthony Nadalin/Austin/IBM@IBMUS cc <>, <> Subject RE: [wss] xml:id proposal > As I read the specification, the usage of xml:Id causes issues with "classic" C14N Please inform us of the issues you see. >(2) No element should be allowed to have more than one id attribute so any element that has a schema that defines an id already cannot. I agree as long as the schema defines the id attribute to be mandatory. If it is optional then I think xml:id is a possible replacement for an optionally defined id attribute in the schema. > So at best I think that at best this is a "may implement" , not a SHOULD or MUST. Please note that Frederick’s original proposal had a MUST for what a Receiver was supposed to do. An important change that I made was that I changed this MUST to a MAY. But you seem to be describing that you want the MAY to apply to Senders. Can you please tell us exactly what SHOULD or MUST you want changed? /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Nepean, Ontario K2E 6A3 Tel: (613) 225-5445 Fax: (425) 936-7329 mailto: From: Anthony Nadalin [mailto:] Sent: September 3, 2005 12:56 PM To: Paul Cotton Cc: ; Subject: RE: [wss] xml:id proposal Couple of issues: (1) As I read the specification, the usage of xml:Id causes issues with "classic" C14N, we have identified use cases where Inclusive C14N is a requirement and where exe-C14N will not work. (2) No element should be allowed to have more than one id attribute so any element that has a schema that defines an id already cannot. So at best I think that at best this is a "may implement" , not a SHOULD or MUST. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 "Paul Cotton" <> "Paul Cotton" <> 09/01/2005 01:04 PM To <> cc <> Subject RE: [wss] xml:id proposal I would like to offer a series of amendments to your proposal. I am offering these amendments since I believe: a) we need to ensure that WSS 1.1 is as backwards compatible as possible with WSS 1.0 b) we should NOT mandate the immediate implementation of xml:id since it will take some time for implementations to adopt the future W3C Recommendation (but we should permit it) c) your proposed text incorrectly asserts that xml:id is of "schema type ID". I believe my amendments still help achieve what you want to do and hope that the TC will be able to adopt the amended proposal. /paulc > Add to section 4, ID References, > > (1) Replace "attribute" at line 494 with > > "attribute and the xml:id attribute [XMLID]." I support this change since the list is prefaced with "also allows use". > XMLID is a reference to the W3C XML ID Recommendation, to be added to > the references section of the document. > > (2) Add additional bullet after line 500: > * Global xml:id attributes on elements I support this change since it just is a list of types of ids. > (3) Add following paragraph right before 4.1, after line 504 > > Tokens and elements that are defined in this specification and > related profiles to use wsu:Id attributes should do so, additional > profiles and other elements to be signed may choose to use xml:id or > wsu:Id. All receivers MUST be able to identify XML elements carrying > either a wsu:Id or an xml:id attribute as representing an attribute > of schema type ID and process it accordingly. Rationale: We cannot make support of xml:id mandatory since it breaks backwards compatibility with WSS 1.0 and it is inappropriate to force implementers to support xml:id so soon after it becomes a Recommendation. Note as well that xml:id attributes are NOT of "schema type ID". I propose to substitute the following text for the above change: Tokens and elements that are defined in this specification and related profiles to use wsu:Id attributes should do so, additional profiles and other elements to be signed may choose to use xml:id or wsu:Id. All receivers MUST be able to identify XML elements carrying a wsu:Id attribute as representing an attribute of schema type ID and process it accordingly. All receivers SHOULD be able to identify XML elements carrying a xml:id attribute as representing an id attribute and process it accordingly. > (4) Add following to end of last paragraph in 4.1, at line 521 > > In addition, the xml:id attribute may be used. Applications MUST NOT > specify both a wsu:ID and xml:id attribute on a single element, this > is an XML requirement that only one attribute of type xsd:ID be > specified on a single element. Rationale: Again xml:id attributes are NOT of "schema type xsd:ID". I propose to substitute the following text for the above change: In addition, the xml:id attribute may be used. Applications MUST NOT specify both a wsu:ID and xml:id attribute on a single element. It is an XML requirement that only one id attribute be specified on a single element. > > (5) Change following into 4.2 Id Schema, at line 550: > > Replace > "this attribute definition into their parsers" > > with > "this attribute definition and that of xml:id into their parsers" Rationale: I do not think this change is correct since it implies that xml:id is of "schema type xsd:ID" and this is NOT correct. I propose that no change is needed to Section 4.2 since it only needs to discuss wsu:ID which it already does. /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Nepean, Ontario K2E 6A3 Tel: (613) 225-5445 Fax: (425) 936-7329 mailto: > -----Original Message----- > From: Frederick Hirsch [mailto:] > Sent: August 31, 2005 5:19 PM > To: Oasis WSS > Cc: Frederick Hirsch > Subject: [wss] xml:id proposal > > Here is a concrete proposal to add xml:id to WSS 1.1 core, in > response to public review comment. > > Line numbers below refer to latest draft which is public review with > subsequent committee changes [1] > > Add to section 4, ID References, > > (1) Replace "attribute" at line 494 with > > "attribute and the xml:id attribute [XMLID]." > > XMLID is a reference to the W3C XML ID Recommendation, to be added to > the references section of the document. > > (2) Add additional bullet after line 500: > * Global xml:id attributes on elements > > (3) Add following paragraph right before 4.1, after line 504 > > Tokens and elements that are defined in this specification and > related profiles to use wsu:Id attributes should do so, additional > profiles and other elements to be signed may choose to use xml:id or > wsu:Id. All receivers MUST be able to identify XML elements carrying > either a wsu:Id or an xml:id attribute as representing an attribute > of schema type ID and process it accordingly. > > (4) Add following to end of last paragraph in 4.1, at line 521 > > In addition, the xml:id attribute may be used. Applications MUST NOT > specify both a wsu:ID and xml:id attribute on a single element, this > is an XML requirement that only one attribute of type xsd:ID be > specified on a single element. > > (5) Change following into 4.2 Id Schema, at line 550: > > Replace > "this attribute definition into their parsers" > > with > "this attribute definition and that of xml:id into their parsers" > > Attached is a red-lined PDF showing these changes in context, based > on the public review draft (with the line added in the latest draft > also marked). > > I propose we resolve this issue at the 19 Sept WSS call, since that > should allow better information regarding the status of xml:id > reaching W3C Recommendation status (earliest date of Recommendation > is 9 September). > > regards, Frederick > > Frederick Hirsch > Nokia > > > [1] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/ > 13961/wss-v1.1-spec-draft-SOAPMessageSecurity-01.pdf --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread →
Next in month →