[uf-dev] include-pattern testing

[Tantek Ç elik]

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