Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] Legal code and technical implementation: your input wanted

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Nathan Kinkade <nkinkade AT creativecommons.org>
  • To: Dan Mills <dan AT creativecommons.org>
  • Cc: creative commons developers <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] Legal code and technical implementation: your input wanted
  • Date: Thu, 18 Apr 2013 13:45:22 -0400

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> 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
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>




Archive powered by MHonArc 2.6.24.

Top of Page