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
