I'm not sure that would work, unless you are suggesting that /legalcode be the bare-bones version and we generally link to /explained instead. If so, skip to the bottom of my reply :)
The problem is that the license, when prepared for human consumption, benefits from changes in its surroundings. For example: (1) user visits the deed. It might be required for the legal code to be included there in some form (such as an expanding widget, for example). This is what I'm hearing from the legal team - it's not 100% clear yet, but a possibility. In such a setting, the legal code would need to - not contain the big header - not include the "back to deed" link at the bottom - not include links to translations being proposed for the legalcode page (the deed already has locale links) (2) user visits the legal code page. It makes sense to have the above, plus potentially other tools for e.g. viewing errata changes in-context. Maybe what you meant is something like: deed: links to /explained (not /legalcode). /explained: web readable version generated from /legalcode /legalcode: hand-edited bare-bones document with no JS or stylesheets. If so, that's closer to what I proposed, except that it changes what /legalcode is today somewhat. I think we should have the URLs serve the purpose they serve today, just invert how they are generated: deed: links to /legalcode (as it does today) /legalcode: generated from /legalcode-plain /legalcode-plain: hand-edited bare-bones document with no JS or stylesheets. Dan On Thursday, April 18, 2013 at 11:30 AM, Maarten Zeinstra wrote: > I think we're almost there. > > Let's say we have one HTML document that contains the license. It is mark > with css classes and anchors. Now webtechnology can be created and or exists > to embed that document. What I am getting at is that something like > > http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode > > should consist of only one document with css designed for print, mobile > devices, and regular screens, in may include js for errata > > But let's only have one document! Let's not have it marked up in one markup > language and presented in another, let's have one document. That's all I am > saying. > > Now if you want to add functionality, do not do it on the legalcode page. For > example if you want to create a product say: > > http://creativecommons.org/licenses/by-nc-nd/3.0/explained > > You should use javascript or similar tech. to fetch the legalcode page and > work from that to add functionality. > > -- > Kennisland > | www.kennisland.nl (http://www.kennisland.nl) | t +31205756720 | m > +31643053919 | @mzeinstra > > > > > > > > > > On Apr 18, 2013, at 20:20 , Dan Mills <[email protected] > (mailto:[email protected])> wrote: > > Can you explain a bit more what you mean? Not sure I get how it's different > > from what I'm suggesting. > > > > Dan > > > > > > On Thursday, April 18, 2013 at 11:19 AM, Dan Mills wrote: > > > > > This is not actually about Markdown. > > > > > > This is about having a minimal document that we transform into the page > > > the user sees, by adding styling, headers, errata, links to translations, > > > or whatever the legal team wants to add. Markdown is just one example of > > > a format that would make that easy. > > > > > > I completely agree that there should be some immutable version of the > > > license, the discussion is about what that should look like. > > > > > > Dan > > > > > > > > > On Thursday, April 18, 2013 at 11:14 AM, Maarten Zeinstra wrote: > > > > > > > But really that is just silly. > > > > > > > > What legal is requesting is a way to get to the 'real' legal code, but > > > > actually they are asking for a simple representation of that code. As I > > > > see it they want something like a 'print-version' of the legal code. > > > > That would still mean that there is markup in some way. > > > > > > > > I would have one basic html document, slightly different than Kinkades > > > > example (I would stack css classes), and have two pages. One for web > > > > viewing and another completely dressed down for print. > > > > > > > > I think given the option of a print version or a markdown version the > > > > legal-team will probably choose the former. > > > > > > > > -- > > > > Kennisland > > > > | www.kennisland.nl (http://www.kennisland.nl/) | t +31205756720 | m > > > > +31643053919 | @mzeinstra > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 18, 2013, at 20:10 , Dan Mills <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > No, end users would use HTML when used in a web context, of course. > > > > > But consider the two use-cases I mentioned: > > > > > > > > > > * Adding translation links at the bottom of the legal code page. > > > > > * Embedding the legal code into the deed in some manner. > > > > > > > > > > Both are HTML for the end user, but *different HTML*. > > > > > > > > > > So again, the point is that we need: > > > > > > > > > > 1) a *minimal* format to express the licenses themselves, and nothing > > > > > more. > > > > > 2) some tooling to take those licenses and format them as needed > > > > > depending on context. > > > > > > > > > > And although we could write that tooling today with the HTML as-is, I > > > > > would *much* rather write tools that know less about the license > > > > > content. > > > > > > > > > > Dan > > > > > > > > > > > > > > > On Thursday, April 18, 2013 at 10:57 AM, Greg Grossmeier wrote: > > > > > > > > > > > I guess the miscommunication here is: > > > > > > what tooling will you build that needs to use something other than > > > > > > HTML > > > > > > to display the license? > > > > > > > > > > > > What use-case do you have in mind, Dan? > > > > > > > > > > > > Greg > > > > > > > > > > > > <quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700"> > > > > > > > Hi, > > > > > > > > > > > > > > The licenses still contain too much information which is not > > > > > > > actually part of the licenses. Just open that link, view source, > > > > > > > and behold. > > > > > > > > > > > > > > Of course we could parse it, but how would you decide what you > > > > > > > can remove and what is part of the license? We need to minimize > > > > > > > the amount of code that has such decisions embedded in it. > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > On Thursday, April 18, 2013 at 10:45 AM, Nathan Kinkade wrote: > > > > > > > > > > > > > > > All of the CC licenses validate as XHTML 1.0 Transitional. > > > > > > > > There are > > > > > > > > a lot of really great XML parsers out there for manipulating > > > > > > > > such > > > > > > > > documents. It would be trivial for us to clean up the HTML in > > > > > > > > the 4.0 > > > > > > > > licenses to more minimal, using better nesting of id and > > > > > > > > classes so we > > > > > > > > can use more accurate CSS selectors, and javascript can more > > > > > > > > reliably > > > > > > > > navigate the DOM. I have already started this when I put > > > > > > > > together the > > > > > > > > Draft 3 of the 4.0 licenses by giving a unique ID to each > > > > > > > > section and > > > > > > > > subsection: > > > > > > > > > > > > > > > > http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B > > > > > > > > > > > > > > > > Nathan > > > > > > > > > > > > > > > > On Thu, Apr 18, 2013 at 1:30 PM, Dan Mills > > > > > > > > <[email protected] (mailto:[email protected]) > > > > > > > > (mailto:[email protected])> wrote: > > > > > > > > > Hi Bjorn & Maarten, > > > > > > > > > > > > > > > > > > I think you're missing a key point that Kat is making: the > > > > > > > > > legal team is > > > > > > > > > looking to change the pages that the licenses are on, to add > > > > > > > > > translation > > > > > > > > > links. I also know that they are thinking about ways of > > > > > > > > > including the > > > > > > > > > licenses inside the deeds, which would also require some > > > > > > > > > changes to the > > > > > > > > > license pages. > > > > > > > > > > > > > > > > > > So the point is not "what do you think of Markdown" in a > > > > > > > > > vacuum, it's: what > > > > > > > > > format can we store that contains only the absolute minimum > > > > > > > > > to be > > > > > > > > > considered to be part of the licenses, so that we can build > > > > > > > > > tooling to style > > > > > > > > > it appropriately depending on the context. > > > > > > > > > > > > > > > > > > We could obviously write tooling that takes the current HTML > > > > > > > > > and transforms > > > > > > > > > it, but such tooling would need to be highly content-aware: > > > > > > > > > it would need to > > > > > > > > > know which parts of the HTML file it can remove or change, > > > > > > > > > and which ones it > > > > > > > > > cannot. We likely can't eliminate that completely regardless > > > > > > > > > of the format, > > > > > > > > > but we should try to minimize it. > > > > > > > > > > > > > > > > > > Markdown seems pretty close to the minimal format that lets > > > > > > > > > us express what > > > > > > > > > we need. We could also continue to use HTML, but we'd need to > > > > > > > > > use a minimal > > > > > > > > > subset--not what we use now (which includes images, scripts, > > > > > > > > > links not part > > > > > > > > > of the license, etc). > > > > > > > > > > > > > > > > > > So, looking at your (Maarten's) four points with this in mind: > > > > > > > > > > > > > > > > > > 1. Both markdown and HTML (HyperText Markup Language) are > > > > > > > > > markup > > > > > > > > > languages, it seems silly to convert one markup language into > > > > > > > > > another. > > > > > > > > > > > > > > > > > > > > > > > > > > > This is not a criteria for choosing a format to use. > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > It does, but the alternative is an HTML->HTML transformation, > > > > > > > > > which is > > > > > > > > > arguably more complex because HTML is so expressive. We could > > > > > > > > > make it work > > > > > > > > > if we enforced a very limited subset of HTML as the input, > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. Markdown is not a standard and we cannot rely on it to > > > > > > > > > stay the > > > > > > > > > same, HTML is. > > > > > > > > > > > > > > > > > > > > > > > > > > > This is not actually true, the history of HTML is littered > > > > > > > > > with examples: > > > > > > > > > > > > > > > > > > http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements > > > > > > > > > > > > > > > > > > But you're right that Markdown is not currently led by any > > > > > > > > > large standards > > > > > > > > > body. I think there are two mitigating factors: > > > > > > > > > > > > > > > > > > (a) The primary uses for these files will be: > > > > > > > > > > > > > > > > > > - to be transformed for general consumption, and > > > > > > > > > - to serve as an archive. > > > > > > > > > > > > > > > > > > The first is internal to CC only, the second requires at most > > > > > > > > > that the file > > > > > > > > > be readable at some point in the future without our help. In > > > > > > > > > other words, we > > > > > > > > > do not need every client (browser) to natively understand the > > > > > > > > > format. > > > > > > > > > > > > > > > > > > (b) Markdown is so incredibly simple, it's hard to imagine a > > > > > > > > > future where > > > > > > > > > someone will be unable to read it: > > > > > > > > > > > > > > > > > > http://etherpad.creativecommons.org/p/markdown-example > > > > > > > > > > > > > > > > > > 4. Markdown basically is short hand for HTML, again why would > > > > > > > > > we use it? > > > > > > > > > > > > > > > > > > > > > > > > > > > Simplicity, and as a forcing function to get us to stop > > > > > > > > > putting in > > > > > > > > > extraneous content in our licenses. > > > > > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > cc-devel mailing list > > > > > > > > > [email protected] > > > > > > > > > (mailto:[email protected]) > > > > > > > > > (mailto:[email protected]) > > > > > > > > > http://lists.ibiblio.org/mailman/listinfo/cc-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > cc-devel mailing list > > > > > > > [email protected] (mailto:[email protected]) > > > > > > > http://lists.ibiblio.org/mailman/listinfo/cc-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | > > > > > > | http://grossmeier.net (http://grossmeier.net/) A18D 1138 8E47 > > > > > > FAC8 1C7D | > > > > > > _______________________________________________ > > > > > > cc-devel mailing list > > > > > > [email protected] (mailto:[email protected]) > > > > > > http://lists.ibiblio.org/mailman/listinfo/cc-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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
