I agree with Maarten. If it ain't broke don't fix it. grtz BjornW
On 18-04-13 15:12, Maarten Zeinstra wrote: > Hi Kat, > > We've talked about this issue briefly in London. I am glad to see that > what you told me then is reflected in the request for comments, I did > understand you correctly. > > However that also means that I keep to my initial conclusions. This is > definitely not a good idea. I've put my thoughts down below, so we can > break down the discussion into its subparts > > 1. Both markdown and HTML (HyperText Markup Language) are markup > languages, it seems silly to convert one markup language into another. > 2. Adding markdown to the infrastructure creates extra dependancies on > a conversion between markdown and HTML, one that will probably takes > more skill and time than doing these licenses immediately in html > 3. Markdown is not a standard and we cannot rely on it to stay the > same, HTML is. > 4. Markdown basically is short hand for HTML, again why would we use it? > > Finally I've expected the cc-developers list to be consulted first > before the affiliates were consulted. I think the members on this list > are the more tech savvy and have experience in implementing various > technologies. This seems like a very top-down idea with possible good > intention but with a general lack of understanding the consequences of > a decision like this. > > As a sidenote, is CC really willing to invest tech time into fixing > something that is not broken instead of working on actual requests > like adding more metadata-languages and working on the 40 or so unread > bug reports? > > @Greg, Jonas, Bjorn: what are your ideas on this? > > Best, > > Maarten > * > > * > -- > Kennisland * > * > * > | www.kennisland.nl <http://www.kennisland.nl> | t +31205756720 | m > +31643053919 | @mzeinstra > * > * > * > > > * > * > > > On Apr 18, 2013, at 24:57 , Kat Walsh <[email protected] > <mailto:[email protected]>> wrote: > >> Greetings! I think this is my first time posting to this list, so as >> a brief introduction for those who haven't seen me flooding their >> inboxes yet, I've been working in the CC legal team since last June. >> One of the things I'm focusing on is the legal impact of CC's tech >> projects, so you're likely to see more from me in the future. >> >> As we are preparing for the publication of 4.0, there are a few >> implementation details that we would like your feedback on. The rest >> of this message was also posted to the affiliates, and some of the >> questions and descriptions are directed primarily toward them; >> however, your input both as a development community and as people >> aware of how CC's tools are being used would be really valuable on >> some of these questions. >> >> ---- >> >> The first part of this message describes an idea we're considering >> about changing the way the legal code is maintained, and asking how >> (if it all) it would affect you. In the second part, we want to know >> which parts of the published licenses you expect never to change >> after publication. >> >> CC has promised that once the legal code of a license has been >> published, it will never change, and this is a practice we will >> continue with 4.0. Doing this allows people to rely on a single >> version, without having to monitor for changes that may affect their >> understanding of the license. >> >> Currently, when a license is published, the official version is the >> HTML file as published on creativecommons.org >> <http://creativecommons.org/>. For example, for BY-SA-3.0 Unported, >> the official version is located at >> http://creativecommons.org/licenses/by-sa/3.0/legalcode. We are >> considering an idea to separate the legal code from the non-legal >> code elements of the web page more cleanly, and have the part that is >> the legal code itself be in a separate file that will never change, >> while the HTML version may change elements (such as page navigation) >> that are not actually part of the legal code. >> >> If we were to do this, the legal code would be maintained in a >> separate file from the HTML, in a format that maintained all of the >> essential information. For example, formatting such as bold or italic >> text that has legal significance, section headings, etc., would all >> be considered essential and part of the legal code itself. This legal >> code file would likely be maintained using Markdown[1], or something >> similar to it. >> >> The web page with the licenses would be generated from this legal >> code file, by converting it to HTML and adding non-legal code >> formatting, text, and navigational elements. However, since the legal >> code file would not have to be touched, it would be impossible to >> accidentally make a change to the legal code itself by changing other >> elements of the page. >> >> Ultimately, the experience of almost all users of the license would >> be exactly the same: they would see a CC license applied to a work, >> and click through to a page that looks exactly like the current page. >> The experience for affiliates would differ. During the translation >> process, affiliates and translation teams would be editing the legal >> code in its new format, rather than an HTML file. (The markup would >> probably be simple, but it would still be different.) CC HQ would >> also be editing and commenting on these files. Additionally, informed >> license users who wished to rely on the unchanging legal code would >> be able to find it and know that it would always remain stable. >> >> In general, CC doesn't want to disrupt existing processes without >> reasons that justify that change, and we'd like to hear whether this >> would be true for you. Some pros and cons we've identified: >> >> *provides a unchanging file containing all of the essential elements >> of the legal code >> *makes a clean separation between the actual legal code and the way >> it is displayed >> *adds some complexity to the development process >> *introduces some changes to the editing and translation processes, >> including a different format for the legal code >> >> Questions we'd like feedback on: >> 1. Do you think this would be worthwhile? >> 2. Would it make translation and editing more difficult for you and >> your teams? >> >> The second part of this, which is important for us whether or not we >> pursue the first proposal, is that we would like some input on what, >> exactly, must stay the same, and what may change. For example, it >> should be clear that the actual text contained in the license is part >> of the legal code, and therefore it must be kept exactly as is. It >> should also be uncontroversial that the navigational elements on the >> page (directing viewers back to the deed, for example) are not part >> of the legal code, and may be changed. >> >> However, we would like to start thinking about elements that are less >> certain--and in particular, we want to be able to say for certain >> what is part of the legal code and what is not, and we need to settle >> that question in collaboration with you, as community expectations >> around our commitment not to change the legal code are extremely >> important. (For example, is it allowable to add navigation boxes to >> legal code pages that link to other translations of that legal code? >> As translations of CC0 are progressing, this is not a purely >> theoretical question!) >> >> Do you already have expectations about what is part of the legal code >> and cannot change, and what is not? Which elements do you think >> should be able to change, and which should not? >> >> We really appreciate your input on these questions. >> >> Thanks, >> Kat >> >> -- >> Kat Walsh, Counsel, Creative Commons >> IM/IRC/@/etc: mindspillage * phone: please email first >> Help us support the commons: https://creativecommons.net/donate/ >> CC does not and cannot give legal advice. If you need legal advice, >> please consult your attorney. >> _______________________________________________ >> cc-devel mailing list >> [email protected] <mailto:[email protected]> >> http://lists.ibiblio.org/mailman/listinfo/cc-devel > > > > _______________________________________________ > cc-devel mailing list > [email protected] > http://lists.ibiblio.org/mailman/listinfo/cc-devel -- met vriendelijke groet, Bjorn Wijers * b u r o b j o r n .nl * digitaal vakmanschap | digital craftsmanship Werkdagen: Van maandag t/m donderdag vanaf 10:00 Vrijdag is voor experimenteren en eigen projecten. Postbus 14145 3508 SE Utrecht The Netherlands tel: +31 6 49 74 78 70 http://www.burobjorn.nl _______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
