[uf-dev] include-pattern testing

[Ryan King]

It appears that the "put it on the wiki suggestion" killed the  
conversation.

I'd like to push ahead with this, even if we don't have everything  
laid out on the wiki yet.

I'd like to push it forward, because I'd really like to *finally*  
publish the hcard tests I've been working on, and this issue is  
blocking that.

I'm going to raise the issue on the discuss list and see if I can  
build some consensus.

-ryan

On May 1, 2006, at 3:07 PM, Tantek Çelik wrote:

> Dan, that is a good summary.  Though I might weight the +/-s  
> differently, I
> cannot disagree with their existence.
>
> Go ahead and document your description of the alternatives here on  
> the wiki:
>
>  http://microformats.org/wiki/include-pattern-issues
>
> Thanks,
>
> Tantek
>
> P.S. Regarding, "that's what the wiki says", I'm the one who wrote  
> it on the
> wiki ;) and I'm open to considering the change without any penalty  
> for it
> being a change from what is on the wiki.
>
> On 5/1/06 1:10 PM, "Dan Connolly" <connolly at w3.org> wrote:
>
>> On Mon, 2006-05-01 at 14:03 -0500, brian suda wrote:
>>> Ryan King wrote:
>>>> On Apr 29, 2006, at 11:02 AM, Tantek Çelik wrote:
>>>>> On 4/29/06 9:40 AM, "Brian Suda" <brian.suda at gmail.com> wrote:
>>>>>> 2) The easy fix would be to lobby to change th include-pattern  
>>>>>> so that
>>>>>> the #ref-id acts like a 'root node' and we only look to the  
>>>>>> children
>>>>>> of that (the way X2V currently works)
>>>>>
>>>>> I am open to this change, I don't think it would break the  
>>>>> examples
>>>>> we have.
>>>>
>>>> I don't think so.
>>>>
>>>> In the wiki example (re: James Levine), the <object> refers to #j,
>>>> which is the .fn.n of the main hCard. If we were to change  
>>>> things so
>>>> that the include pattern only looked at children, that example  
>>>> would
>>>> either need to add another layer of markup (around the .fn.n) or  
>>>> the
>>>> include-pattern would have to refer to the entire hCard. I don't  
>>>> think
>>>> this is as convenient.
>>>>
>>>> I think the ability to point straight at the element to be  
>>>> included is
>>>> a feature worth having, even if it makes parsing more difficult.
>>> Then this becomes true
>>>
>>> <object class="vcard agent fn include" id="self" data="#self"
>>> type="text/html">Brian Suda</object>
>>
>> Not necessarily; the include pattern introduced the possibility of
>> loops before we got into the issue of whether the referenced element
>> or only its children are parsed. I think it's straightforward
>> to prohibit loops regardless of which way this design choice goes.
>>
>> I don't see a compelling argument either way. Here's what
>> I see so far:
>>
>> (a) include-pattern works on the referenced element and its children
>> + it's easier for authors (that's an argument Ryan made that
>>    I can agree with from 1st-hand experience)
>> + that's what the wiki says
>> + that's what the test I checked in says
>> - x2v doesn't (yet?) support it
>>   (and adding support looks like it will complicate the code a bit)
>>
>> (b) include-pattern works only on children of the referenced element
>> - it's harder for authors
>> - the wiki needs updating
>> - the test I checked in needs changing
>> + x2v already supports it
>> + somebody (who was it?) expressed satisfaction with the way
>>   x2v supports it
>>
>>
>> I'm not sure what's a good process for this sort of issue; clearly
>> the -dev list is not the only place to take input, as it's naturally
>> biased toward ease of implementation at the cost of author  
>> convenience.
>> I guess that argument summary should go in the wiki?
>>
>> http://microformats.org/wiki/include-pattern
>>
>>> now what does that mean? I found a vcard, and an include, so i go  
>>> fetch
>>> the data, which is fn, agent vcard and include? I know we can  
>>> avoid the
>>> whole recursive portion, but we are now flattening out 'vcard and  
>>> fn'
>>> and giving ambiguity to agent?
>>>
>>> I agree that not pointing directly to the data with the #id-ref,  
>>> but to
>>> it's parent is not as convenient, but i think from a parsing  
>>> "include"
>>> perspective it is needed.
>>>
>>> -brian
>
> _______________________________________________
> microformats-dev mailing list
> microformats-dev at microformats.org
> http://microformats.org/mailman/listinfo/microformats-dev

--
Ryan King
ryan at technorati.com