Hi Dan, Ok, I see that you mean a bit more now, but can't we do it the other way around?
Embed the license pages as they are proposed by us into a more rich page? However I would never ever endorse a view where the URI of the licenses are used for other purposes than just showing the best ways to read the licenses on the web. -- Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 | @mzeinstra On Apr 18, 2013, at 20:14 , Maarten Zeinstra <[email protected]> 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 | t +31205756720 | m +31643053919 | @mzeinstra > > > > > On Apr 18, 2013, at 20:10 , Dan Mills <[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])> 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 >
_______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
