If we are going to put more logic in the attributes themselves, then one might
as well make it more redable and go all the way, and have the AND/OR/NOT in the
attributes.
I also like the fact that indeed attributes don't participate in the
processing, and it's all in the node and attribute names.
Now, here are more thoughts on this. Please my apologies if I am going quite
far from the initial discussion: these are just random thoughts, not something
I strongly or advocate for. Just food for thought. I want to let more
knowledgeable person make the specs and take decisions, but maybe this can give
more ideas.
Part of the discussion also boils down to the issue of readability vs syntax
consistency (vs brevity??): do we want the code to be easily readable? Or
easily amenable to automation and optimized for fast processing? I think the
choice of XML is already not aiming at readability, and the issue raised by
Frank is one of readability (a concept to which implicitely includes
writability): to generate more complex predicates, one needs nested <if>. It
will always be a difficult balance to strike, and that points again to the need
for tools on top of the language that help build this kind of predicates.
So, if we want to have more complex predicates, I would argue the syntax should
bring more readability. While the 'not:' syntax is easy to understand, all the
'all', 'match', 'any' attributes are quite hard to understand. I don't think
this line is readable, for instance, and it's really hard to understand what is
going on:
<if type="article-journal" variable="volume issue" variable-match="all"
is-numeric="volume issue" is-numeric match="nand" match="all">
In a way, I prefer the current nested but still easier to parse mentally
conditionals.
Now, I like better the idea of new node types to allow a more reable syntax for
complex predicates, similar to what Frank suggests below, but maybe go straight
to what we really want:
<if type="article-journal">
<or variable="volume issue" variable="volume" variable = "issue" />
<text variable = "volume">
<if />
<if type="article-journal">
<or variable="volume" />
<or variable="volume" />
<text variable = "volume">
<if />
<if type="article-journal">
<and>
<not variable="volume" />
<or variable="issue" />
<and />
<text variable = "volume">
<if />
with some implicit `and` when multiple attributes are in the <if>, <and>, <or>
or <not> nodes. As to operator precedence etc… I will let years of CS
development make the decision. After all, logic is the mother of all computing
:-)
I just like how the stuff above is readable and I believe it's very easy to
process as well.
Charles
On Apr 16, 2013, at 6:18 AM, Frank Bennett <[email protected]> wrote:
> Bruce: Absolutely. The original syntax is very clean and makes good
> sense. This just aims to add a little more expressiveness, to cope
> with some of the more complex styles that we've encountered in the
> wild.
>
> It looks like we have suggestions running in two directions. We could
> move the "not:" condition from the argument to an attribute, making
> things more readable but losing some expressiveness (Rintze); or we
> could move the match logic into the argument as well, again improving
> readability but with more complex semantics (Andrea).
>
> My feeling is that the more expressiveness we have, the better, within
> reasonable limits of complexity for validation (on one side) and
> implementation (on the other). I think the original proposal strikes
> that balance, but I'm still learning.
>
> For maximum expressiveness, a single attribute that recognizes an
> XSLT-like syntax (?) would give us everything we could possibly need,
> at the cost of considerable pain on the validation side. Something
> like:
>
> condition="and(
> type(article-journal),
> variable(volume),
> variable(issue),
> or(
> not(variable(volume)),
> not(variable(issue))
> )
> )"
>
> That's not a fresh proposal -- just thinking out loud about possibilities.
>
>
>
> On Tue, Apr 16, 2013 at 3:47 AM, andrea rossato <[email protected]>
> wrote:
>> "Bruce D'Arcus" <[email protected]> writes:
>>
>>> So as a first comment (will look at details later, though I have
>>> confidence it's well thought-out given the background work you've
>>> done, Frank; thanks for that), let me explain why the syntax is the
>>> way it is. E.g. it wasn't an accident.
>>>
>>> Given that CSL is an XML language, I really wanted to keep the
>>> language as clean to process as possible using the most pure XML
>>> processing language extant: XSLT.
>>>
>>> So the idea was any significant CSL logic was represented in terms of
>>> native XML structures: nodes (elements and attributes) and values.
>>>
>>> Going this route, where the values themselves take on core logical
>>> semantics, and where those values themselves must be processed (though
>>> admittedly, the processing is simple here; just split on a colon and
>>> treat as key-value), is a change in direction.
>>
>> This is quite a strong argument, indeed. I wonder if we could increase
>> the conditional expressiveness by just permitting boolean connectors
>> (and, or, xor, plus the prefix not:) inside attributes.
>>
>> Something like:
>>
>> <if type-all="article-journal" variable-all="volume issue"
>> is-numeric-any="not:volume not:issue" match="all">
>>
>> could be expressed:
>>
>> <if type="article-journal" variable="volume and issue"
>> is-numeric="not:volume or not:issue" match="all">
>>
>> (possibly 'or' could be the default).
>>
>> Just a thought.
>> --
>> andrea
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> xbiblio-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> xbiblio-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
--
Charles Parnot
[email protected]
twitter: @cparnot
http://mekentosj.com
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
