W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > July 2007

[fwd] RE: intent to squat on xpointer() -- normative reference issue(ACTION-66) (from: pgrosso@ptc.com)

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 18 Jul 2007 18:51:46 +0200
To: public-xmlsec-maintwg@w3.org
Cc: pgrosso@ptc.com
Message-ID: <20070718165146.GL9569@raktajino.does-not-exist.org>

Forwarding to the WG list, since the list software was a bit too
clever for its own good.  Thanks Paul!
-- 
Thomas Roessler, W3C  <tlr@w3.org>






----- Forwarded message from "Grosso, Paul" <pgrosso@ptc.com> -----

From: "Grosso, Paul" <pgrosso@ptc.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: Thomas Roessler <tlr@w3.org>, w3c-xml-cg@w3.org,
	public-xmlsec-maintwg@w3.org
Date: Wed, 18 Jul 2007 12:18:08 -0400
Subject: RE: intent to squat on xpointer() -- normative reference issue(ACTION-66)
X-Spam-Level: 
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5

The XML Core WG just met and discussed this issue.

There are no good solutions.  We realize that you have
an existing Recommendation that has referenced xpointer(),
and you have implementations that support this.

We recommend in the next edition of the Rec that you
reference the latest version of xpointer (which is the 
WD) as opposed to the (failed) CR, and explain in your 
spec what implementations should do in terms of the
existing XPointer Recommendations as you've suggested
in your message.

The wordings in your message below seem fine to me.
One question and one other issue remain.

My only remaining question is whether it is the case
that the spec will allow only those two forms of xpointer,
or if the spec allows other forms to be supported.  Since
xpointer doesn't really exist, if you can live with just
#xpointer(/) and #xpointer(id('ID')), those are the only
forms you should allow and the spec should make that clear.

Finally, the claim that the XPointer Framework Recommendation
says that the use of such an xpointer implies that comments
are not preserved is false.  I assume it is due to a misreading
of the Conformance section that says:

 XPointer processor behaviour depends on the availability
 of certain information from an XML resource: in the terms
 provided by the [Infoset], the information items and
 properties tabulated below may be relevant. 

and that then lists some items that do not include comments.

All that wording is saying is that the listed information
items are used to define the locating behavior of XPointer.
Once an element is located, the entire element (and all of
its contents) is considered part of the target of the XPointer.
The XPointer spec itself is only about locating.  It says 
nothing about what to do with what is located, but if some
process is going to reference/retrieve something located
by XPointer, there is no reason to assume it wouldn't 
reference/retrieve the entire contents of the located item.

Please remove the incorrect text saying that use of XPointer
implies loss of comments.

paul

> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
> Sent: Tuesday, 2007 July 17 12:18
> To: Grosso, Paul
> Cc: Frederick Hirsch; Thomas Roessler; w3c-xml-cg@w3.org; 
> public-xmlsec-maintwg@w3.org
> Subject: Re: intent to squat on xpointer() -- normative 
> reference issue(ACTION-66)
> 
> Paul
> 
> Thanks for thinking about what we are doing. I'd like to make sure I  
> understand where we are with this set of changes.
> 
> I think we all agree that it is an improvement to reference the  
> XPointer Framework Recommendation rather than an old XPointer CR  
> draft that is no longer being developed.
> 
> Along with that we can make some changes to XML Signature to adjust  
> to XPointer Framework and Element() Scheme Recommendations, 
> and doing that is also good.
> 
> This then leaves us with the issue of how to deal with a bit a  
> material that became part of the Signature Recommendation that was  
> based on a CR draft which then which did not progress to a 
> subsequent REC.
> 
> We think we can do this in a way that does not impact conformance of  
> existing implementations and yet which allows us to reference the  
> current recommendations (and does not make assumptions about future  
> work either)
> 
> This is to add the following two statements to XML Signature
> 
> >  '#xpointer(/)' MUST be interpreted to identify the root node
> >  [XPath] of the document that contains the URI attribute.
> >
> 
> This is necessary, as Thomas noted, due to the need to deal with XML  
> comments that may be outside the document element. Is this statement  
> incorrect regarding the interpretation it requires?
> 
> The following
> 
> >  '#xpointer(id('ID'))' MUST be interpreted to identify the element
> >  node identified by '#element(ID)' [XPointer-Element] when
> >  evaluated with respect to the document that contains the URI
> >  attribute.
> 
> What this does is map existing usage based on the current XML  
> Signature REC to the preferred approach based on XPointer scheme -  
> necessary if we reference the current RECs instead of the old CR  
> draft. Is this clarifying statement incorrect?
> 
> I admit that this is an unfortunate situation based on anticipating  
> the progression of a draft document as to be used as a normative  
> reference in a REC, when that progression didn't work out the way  
> expected after the REC was completed.
> 
> Thanks
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> On Jul 17, 2007, at 11:31 AM, ext Grosso, Paul wrote:
> 
> >
> >
> >
> >> -----Original Message-----
> >> From: Thomas Roessler [mailto:tlr@w3.org]
> >> Sent: Tuesday, 2007 July 17 10:20
> >> To: Grosso, Paul
> >> Cc: w3c-xml-cg@w3.org; public-xmlsec-maintwg@w3.org
> >> Subject: Re: intent to squat on xpointer() -- normative
> >> reference issue(ACTION-66)
> >
> >> See above: The failed XPointer Candidate Rec has been part of a
> >> normative requirement in a successful Rec for the past five years.
> >> That's where we're starting from.
> >
> > Then there isn't really any discussion that can be had.
> >
> > Just as one cannot form a coherent logical argument based on
> > a false hypothesis, one cannot develop a coherent Recommendation
> > that is normatively based on something that doesn't exist, the
> > fact that you've already done that notwithstanding.
> >
> > If you define the problem to be just that, you've defined
> > a universe in which modus ponens is irrelevant, so I'm
> > not sure how to proceed from here.
> >
> > paul
> >
> 



----- End forwarded message -----
Received on Wednesday, 18 July 2007 16:51:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:00 GMT