W3C home > Mailing lists > Public > public-powderwg@w3.org > January 2009

RE: PROPOSED RESOLUTION (WAS Re: [Fwd: About include/excludeiripattern])

From: Smith, Kevin, (R&D) VF-Group <Kevin.Smith@vodafone.com>
Date: Tue, 6 Jan 2009 11:00:10 +0100
Message-ID: <37AC1116121D3F43B9A67CB16E2E79FFC117C2@VF-MBX11.internal.vodafone.com>
To: "Phil Archer" <phil@philarcher.org>, "Andrea Perego" <andrea.perego@uninsubria.it>
Cc: "Public POWDER" <public-powderwg@w3.org>

Hopefully querycontains should be fixed within the hour - I hadn't
realised that XSLT 2 was not entirely backward compatible with 1.0!

-----Original Message-----
From: public-powderwg-request@w3.org
[mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
Sent: 06 January 2009 09:52
To: Andrea Perego
Cc: Public POWDER
Subject: Re: PROPOSED RESOLUTION (WAS Re: [Fwd: About

OK, taking on board the general mood expressed in this thread, I've
written some alternative wording for the relevant section.

See http://philarcher.org/powder/grouping/20090106.html#wild

It still credits the WAF group but the reference is now informative and
is to the FPWD, not their latest draft.


Incidentally, it's not implemented yet in the P to P-BASE XSLT but if
Kevin has time to fix the query contains section of it, I am reasonably
confident that my copy, paste and edit skills will allow me to create
the relevant angle brackets to support this.


Andrea Perego wrote:
> I agree with you, Phil. Probably my comment was not clear. I summarise

> here the issue for those who are not aware of it.
> The constraints include/excludeiripattern have been included in the 
> POWDER specs [1] since there existed a W3C WD proposing a pattern 
> syntax for URLs, namely the "access item" syntax defined by WAF [2].
> So, the idea was to provide support to a possible alternative to the 
> IRI constraints defined in the POWDER specs. As such, this was also 
> meant to be a sort of built-in extension to the genuine POWDER IRI 
> constraints.
> Since in the current WAF specs [3] the definition of the access item 
> syntax has been dropped, include/excludeiripattern cannot any longer 
> be considered  as an implementation of an existing pattern syntax, but

> as constraints adopting a specific IRI pattern syntax defined in the 
> POWDER specs.
> In conclusion, I'm not against keeping include/excludeiripattern, but 
> we need to rephrase the corresponding section in order to explain 
> which is their purpose. In other words,  the paragraph:
> [[
> Enabling Read Access for Web Resources [WAF] defines a method for 
> encoding the domains and sub-domains from which access to resources on

> a given Web site should be granted or denied. The includeiripattern 
> and  excludeiripattern properties support this syntax directly.
> ]]
> needs to be rewritten by saying that include/excludeiripattern are an 
> alternative way of denoting IRIs, specifically designed for URLs, and 
> to denote the domains and sub-domains to which the description 
> applies.
> Andrea
> ----
> [1]http://www.w3.org/TR/powder-grouping/#wild
> [2]http://www.w3.org/TR/2008/WD-access-control-20080214/#access
> [3]http://www.w3.org/TR/2008/WD-access-control-20080912/
> On Mon, Jan 5, 2009 at 5:18 PM, Phil Archer <phil@philarcher.org>
>> Sorry Andrea I'm a tad confused by your comment.
>> If we were to keep this feature then we'd just re-word it a little so

>> as to remove reference to WAF - but everything else would stay the 
>> same. In other words, it's no more work to keep it than to drop it 
>> (except that it's not in the P to P-BASE XSLT, but I'm sure that can 
>> be sorted easily enough once Kevin has debugged the query contains
>> P
>> Andrea Perego wrote:
>>> This might be an option, but I see it more as a way of defining an 
>>> IRI pattern syntax simpler than regular expressions. I'm not sure we

>>> can still propose include/excludeiripatterns as an example of POWDER

>>> extension, at least not referring to Unix glob patterns, which are 
>>> meant for relative / absolute paths, not for IRIs.
>>> Andrea
>>> On Mon, Jan 5, 2009 at 4:16 PM, Stasinos Konstantopoulos 
>>> <konstant@iit.demokritos.gr> wrote:
>>>> why undo work that we have already done? we can simply remove the 
>>>> reference and call them Unix glob patterns or s'thing like that.
>>>> s
>>>> On Mon Jan  5 11:03:48 2009 Phil Archer said:
>>>>> Given the exchange below, I'd like to a) thank Andrea for his 
>>>>> diligence in spotting this, and b) make the rather obvious
proposal that we:
>>>>> Remove the in/excludeiripattern IRI constraint from POWDER (it's 
>>>>> mentioned in the grouping and formal docs).
>>>>> OK?
>>>>> Phil.
>>>>> Anne van Kesteren wrote:
>>>>>> On Mon, 05 Jan 2009 10:32:13 +0100, Phil Archer 
>>>>>> <phil@philarcher.org>
>>>>>> wrote:
>>>>>>> A long, long time ago [1], the POWDER WG had an exchange with 
>>>>>>> Art concerning WAF Access Control. The end result was that we 
>>>>>>> incorporated direct support for the same syntax in POWDER 
>>>>>>> grouping [2], i.e.
>>>>>>> access-item    ::= (scheme "://")? domain-pattern (":" port)? |
>>>>>>> domain-pattern ::= domain | "*." domain
>>>>>>> But, an eagle-eyed member of the group has spotted that the 
>>>>>>> current draft (to which we refer) does not support this any more
>>>>>>> Do we take it that this syntax is no longer supported by your
>>>>>>> [1]
>>>>>>> http://lists.w3.org/Archives/Public/public-powderwg/2007Jul/0004
>>>>>>> .html [2] 
>>>>>>> http://www.w3.org/TR/2008/WD-powder-grouping-20081114/#wild
>>>>>>> [3] http://www.w3.org/TR/access-control/#syntax
>>>>>> My apologies for not notifying your WG, I forgot there was a 
>>>>>> dependency. After thinking through the use cases we are designing

>>>>>> for, we decided upon a much simpler model. I realize this new 
>>>>>> model not work well for you and hope you can find something that 
>>>>>> does (maybe by simply copying our old syntax).
>>>>>> Kind regards,
>>>>> --
>>>>> Phil Archer
>>>>> w. http://philarcher.org/
>> --
>> Phil Archer
>> w. http://philarcher.org/

Phil Archer
w. http://philarcher.org/
Received on Tuesday, 6 January 2009 10:01:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:05 UTC