Hi Greg, I just drafted the same email to Dan:
"You are making me curious. Could you give a either a mockup or a schematic of how you envision this then? Also it appears that most of us oppose this from a technical point of view whereas you are saying that there are reason from legal that are important here as well. Could you explain those view in a way that I can understand them?" Cheers, Maarten -- Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 | @mzeinstra On Apr 18, 2013, at 19:57 , Greg Grossmeier <[email protected]> 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])> 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]) >>>> http://lists.ibiblio.org/mailman/listinfo/cc-devel >>>> >>> >>> >>> >> >> > >> _______________________________________________ >> cc-devel mailing list >> [email protected] >> http://lists.ibiblio.org/mailman/listinfo/cc-devel > > > -- > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | > | http://grossmeier.net A18D 1138 8E47 FAC8 1C7D | > _______________________________________________ > cc-devel mailing list > [email protected] > http://lists.ibiblio.org/mailman/listinfo/cc-devel _______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
