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: Maarten Zeinstra <mz AT kl.nl>
  • To: Dan Mills <dan AT creativecommons.org>
  • Cc: cc-devel AT lists.ibiblio.org
  • Subject: Re: [cc-devel] Legal code and technical implementation: your input wanted
  • Date: Thu, 18 Apr 2013 20:18:17 +0200

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 <mz AT kl.nl> 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 <dan AT creativecommons.org> 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:


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:


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:


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 mailing list


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

_______________________________________________
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