Not necessarily, see the two examples I gave Greg. And there are others which 
we aren't interested in today, but we should know are possible in the future. 
For example: 

http://www.gnu.org/licenses/gpl.html

That page has a ton of stuff that is not part of the GPL itself.

Again - that's not what we want to do at this time, but it's conceivable that 
at some point we might. 

Dan


On Thursday, April 18, 2013 at 11:04 AM, Maarten Zeinstra wrote:

> Well actually ideally it would exactly the same document, but with different 
> css and no js, right?
> 
> Cheers,
> 
> Maarten
> -- 
> Kennisland 
> | www.kennisland.nl (http://www.kennisland.nl) | t +31205756720 | m 
> +31643053919 | @mzeinstra
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Apr 18, 2013, at 20:01 , Dan Mills <[email protected] 
> (mailto:[email protected])> wrote:
> > On Thursday, April 18, 2013 at 10:52 AM, Nathan Yergler wrote:
> > > On Thu, Apr 18, 2013 at 9:32 AM, Mike Linksvayer <[email protected] 
> > > (mailto:[email protected])> wrote:
> > > > On Wed, Apr 17, 2013 at 3:57 PM, Kat Walsh <[email protected] 
> > > > (mailto:[email protected])> wrote:
> > > > > If we were to do this, the legal code would be maintained in a 
> > > > > separate file
> > > > > from the HTML, in a format that maintained all of the essential 
> > > > > information.
> > > > > For example, formatting such as bold or italic text that has legal
> > > > > significance, section headings, etc., would all be considered 
> > > > > essential and
> > > > > part of the legal code itself. This legal code file would likely be
> > > > > maintained using Markdown[1], or something similar to it.
> > > > > 
> > > > > The web page with the licenses would be generated from this legal 
> > > > > code file,
> > > > > by converting it to HTML and adding non-legal code formatting, text, 
> > > > > and
> > > > > navigational elements. However, since the legal code file would not 
> > > > > have to
> > > > > be touched, it would be impossible to accidentally make a change to 
> > > > > the
> > > > > legal code itself by changing other elements of the page.
> > > > > 
> > > > 
> > > > 
> > > > I may have suggested something like this long ago, but I'd probably
> > > > stick to HTML as the canonical version now. That canonical HTML should
> > > > be as minimal as possible, just including enough structure and
> > > > annotation to make it possible for external CSS and Javascript to make
> > > > look pretty and dynamically add further annotation in a variety of
> > > > contexts, and for plain text to be generated without manual post
> > > > processing.
> > > > 
> > > 
> > > 
> > > While you could continue to use javascript, etc for injecting that
> > > sort of customization, I think the burden for creating and maintaining
> > > that sort of code is greater than that for a script that takes a
> > > template document and runs in the actual content.
> > > 
> > 
> > 
> > I very much agree. Client-side JS absolutely has its place, and I have no 
> > problems with using it (heavily, if needed), but it's not some sort of 
> > escape hatch for modifying pages without modifying the page that is served 
> > up. That's just obfuscation, and it's harder to maintain.
> > 
> > > Regardless of the markup format for the "immutable" document, I think
> > > my primary concern is making it easy for a software agent to "follow
> > > its nose" from the license URI to the immutable legalcode. (I
> > > *thought* there was follow-your-nose markup from the deed to the
> > > legalcode, but I don't see it now, so maybe I'm mis-remembering.)
> > > Figuring out what the right predicate is shouldn't be super difficult,
> > > and would fit in the existing ecosystem.
> > > 
> > 
> > 
> > Were you thinking of a link? "The license on this page was generated from 
> > [link]" ?
> >  
> > > 
> > > For what it's worth, we added support for "stripped down" legalcode in
> > > 2010 (I think). For example,
> > > http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
> > > file is generated from the static HTML, and having
> > > markdown/restructured text/something less expressive would have made
> > > life a little easier.
> > > 
> > 
> > 
> > Hah.
> > 
> > Yeah, so that plain format could be close to being acceptable as a *source* 
> > if we really want to use HTML (modulo the stylesheet and JS tags).
> > 
> > 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

Reply via email to