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

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

From: Andrea Perego <andrea.perego@uninsubria.it>
Date: Tue, 6 Jan 2009 22:06:51 +0100
Message-ID: <c730b1640901061306g5f86544ap5f2c2c77f2faa8a1@mail.gmail.com>
To: "Public POWDER" <public-powderwg@w3.org>

+1 from me, Phil.

Andrea


On Tue, Jan 6, 2009 at 10:52 AM, Phil Archer <phil@philarcher.org> wrote:
> 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.
>
> OK??
>
> 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.
>
> P
>
> 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> wrote:
>>>
>>> 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 bit).
>>>
>>> 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 [3].
>>>>>>>>
>>>>>>>> Do we take it that this syntax is no longer supported by your WG?
>>>>>>>>
>>>>>>>> [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 21:07:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:14 GMT