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: Wed, 7 Jan 2009 09:05:58 +0100
Message-ID: <c730b1640901070005lc5b441ax7a98711ebe204df5@mail.gmail.com>
To: "Phil Archer" <phil@philarcher.org>
Cc: "Public POWDER" <public-powderwg@w3.org>
Sorry, the attachment.

Andrea


On Wed, Jan 7, 2009 at 9:01 AM, Andrea Perego
<andrea.perego@uninsubria.it> wrote:
> Phil, I've rechecked the WAF doc, and I suggest a slight change in
> your revision, which is included in the attached doc.
>
> Cheers
>
> 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/


Received on Wednesday, 7 January 2009 08:06:39 GMT

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