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
