Developer discussion for Creative Commons technology and tools

[Greg Grossmeier <greg AT grossmeier.net>]

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 <dan AT creativecommons.org 
> > (mailto:dan AT creativecommons.org)> 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
> > > cc-devel AT lists.ibiblio.org (mailto:cc-devel AT lists.ibiblio.org)
> > > http://lists.ibiblio.org/mailman/listinfo/cc-devel
> > > 
> > 
> > 
> > 
> 
> 

> _______________________________________________
> cc-devel mailing list
> cc-devel AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel


-- 
| Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net           A18D 1138 8E47 FAC8 1C7D |