On Tue, Apr 16, 2013 at 3:25 PM, Charles Parnot <[email protected]> wrote: > 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
I don't know how everyone feels about going for more robust logic (I lean in favour, but that's just me) ... But if there is interest in that, I like this. The only think I would want to add would be a <then></then> wrapper around the rendering element(s) at the end. Frank > > 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 ------------------------------------------------------------------------------ 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
