On Thu, Jan 19, 2012 at 3:41 PM, Charles Parnot
<[email protected]> wrote:
> On Tue, Jan 10, 2012 at 6:15 PM, Charles Parnot
>>> Having branches for processors is indeed an option, though it's up to the
>>> implementor of that processor. It's not too hard to support both in this
>>> case, and makes testing much simpler if you only have one branch.
>>>
>>> Now, where branching could make sense is actually with the styles
>>> themselves. I now see why allowing 1.0.1 styles in the master could be
>>> problematic: as the spec change, that would mean checking all the styles
>>> again, making changes, and potentially messing up some of the styles that
>>> were otehrwise perfectly stable in 1.0. So instead, adding a branch to the
>>> CSL style repo could make sense. That branch would only contain files that
>>> have 1.0.1 features (so the branching should be done from the empty base of
>>> the tree, not from HEAD). Then we could start pushing changes on that
>>> branch. Each implementor could decice wether to include that branch (for
>>> instance, to be honest, Papers would likely also pull from the 1.0.1
>>> styles). Changes in the 1.0.1 specs can be applied to just that branch, and
>>> thus just those few styles. Later, those styles can be merged back into
>>> master, which becomes 1.0.1
>>>
>>> Charles
>
>
> On Jan 10, 2012, at 2:07 PM, Frank Bennett wrote:
>> For legal and multilingual style development, I have a development
>> fork going at https://github.com/fbennett/schema. The diffs for some
>> of the extensions are interdependent, and when trying to maintain
>> atomic commits for each feature, I ended up with cascading
>> sub-branches of contingent feature sets. It because quite hard to
>> follow, and I've given that up in favor of other work;
>>
>> It could be that I'm not using git correctly, though. I have a sort of
>> love-hate relationship with the tool, and there is a lot of
>> misunderstanding. :)
>
>
>
> Indeed, branches can get a bit complicated, particularly if the branches are
> used by several people, and if rules on their use are not explicitly spelled
> out.
>
> But it occured to me we could maybe instead use the following trick, which
> would allow (1) to stick to 1.0 CSL validation in the repository, (2) easily
> switch to 1.0.1 support when it's ready, (3) make it very clear in the CSL
> itself what is happening and (4) allow the clients to postprocess the CSL
> files to their liking in the meantime. That's a bit hacky, but maybe you will
> all like it and want to adopt it, who knows :-)
I'd say yes, it's "a bit hacky" ;-)
Here's a thought:
Part of the problem, it seems to me, is we don't have any clear policy
on small-scale versioning of the schema WRT to processing, so that we
don't really know the impact of particular changes.
But maybe it's possible to come up with such a policy (for sake of
argument, that minor versions can only introduce new attributes, and
that processors can simply ignore them if they wish), such that it's
just not something we need to worry about with styles.
At the point at which we have major version changes (hopefully not for
awhile), we then don't branch, but actually create parallel file
(likes "1.1/apa.csl").
To Frank's issue, I earlier suggested a separate extension schema for
test features, that would simply import and redefine the main csl.rnc
schema.
Bruce
> So the idea would be to use comments for those, which I noticed is already
> done, but in a more standardized way. Here is what I am thinking about for
> instance:
>
> <macro name="author">
> <names variable="author">
> <!-- 1.0.1 ADD
> BEGIN
> <name name-as-sort-order="all" sort-separator=" " initialize-with=""
> delimiter=", " delimiter-precedes-et-al="never"/>
> END -->
> <!-- 1.0.1 REMOVE
> BEGIN -->
> <name name-as-sort-order="all" sort-separator=" " initialize-with=""
> delimiter=", "/>
> <!-- END -->
> <label form="short" prefix=" (" suffix=")" strip-periods="true"/>
> <substitute>
> <names variable="editor"/>
> <names variable="translator"/>
> <text macro="title"/>
> </substitute>
> </names>
>
> This should be fairly easy to automate. It also clarifies the intent to
> anyone reading the XML directly.
>
> What do you think?
>
>
> As a test, I have changed this style in the repo (the resulting CSL is the
> same, just the way things are commented has changed):
>
> https://github.com/citation-style-language/styles/commit/ea7bc629177f67a26f1fc9c28ce6db03a1010863
>
> Charles
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> xbiblio-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
