Re: [SVG 1.2] Other notes.

Robin Berjon wrote:
> Thomas DeWeese wrote:
>> Robin Berjon wrote:
>>> We can encourage implementers to at least display a warning on view 
>>> source when CC data is present, which isn't much to ask for. 
>>    I guess the question is how much RDF parsing do you have to
>> do to figure out if there is CC data or a part description or credit
>> card info or anything else that anyone can imagine putting in the
>> metadata tag of SVG.  Or perhaps CC data embeded in a credit card
>> charge embedded in a Bill of lading etc.
> If all you're planning for is to display a simple warning that the 
> content holds a copyright policy, pretty much all you need to do is to 
> look to see if the document contains the 
> namespace. You could refine that a bit, but at the simplest level that's 
> all that's needed. I remain fairly convinced that that is a very small 
> step.

    Perhaps I'm missing something but this strikes me as an
incredible hack.  Something is in this document is in the CC
namespace so the document is assumed to be Copyrighted?

    Perhaps it's saying it's not protected at all (Public Domain).
Or perhaps the CC data is embedded in a much larger structure
which may have nothing to do directly with this document (it may
refer to works referenced by this document) etc.

    All you could say based on the presence of data in the 'cc'
namespace is that some of the content in this document may or may not
be Copyrighted.  I think you could put up that warning without
the 'cc' data.

> I'm not sure about what you mean concercing credit card information. In 
> this context CC refers to Creative Commons, so there might be a slight 
> misunderstanding ;)

  No misunderstanding :) For example the SVG file might be a print
ready version of a receipt for purchasing CC rights on another work.
In this case it would make lots of sense to embed in the metadata
CC data that grants rights to the other work.  So sure the receipt
has CC data but it doesn't refer to the current document.

   In general I think ignoring the context of the CC data would be
very problematic (perhaps there are options to purchase multiple
levels of CC rights embedded in the document).

>>    What I think is being asked for in a very roundabout manner is
>> a 'bozo bit'.  A simple yes/no flag in the content that says 'allow
>> save'/'don't allow save'.  This could be a simple attribute (perhaps
>> two, one for view and  one for save ) on the root SVG element and the
>> SVG  specification could require User agents to respond to them
>> (similar to how they are required to defeature in the face of 
>> panZoom="disable").
> Graphic artists I have talked to (which I'll admit is just a tiny 
> non-scientific sample) don't trust bozo bits (and they shouldn't, as 
> they don't make intent very clear, in addition to being a fairly ugly 
> hack).

    The purpose of these attributes is not to express legal intent
(that is what CC or Copyright law is about) the purpose is to express
the desired user agent behavior - don't allow the user to save this
file, or view it. This may be because of Copyright or any of 1000
other reasons. Who cares? The User Agent just isn't supposed to
save/view the file.

     This provides no real 'legal' protection for the content that is
what Copyright is for.  It also won't stop a determined user from
saving/viewing the content but very little will (as DeCSS has shown).

> They have concerns about making full quality works available, don't 
> quite realise that SWF does the exact same thing (because getting at the 
> content requires some indirection) and seemed happier to know that 
> inserting a code snipppet gave them legal protection.

    That is fine let them insert the code snippet (BTW CC first
provides you with an equivalent US Copyright statement).  I just
don't like suggesting that SVG User Agents do anything with it.

> Just putting in a little text in a comment at the top is just as 
> binding, but not as simple as filling out the wizard at 
> and pasting the results into their 
> SVG (or better, having something similar in authoring tools).
>>    If this is what people want please don't force implementors to
>> muck with the contents of metadata tags and all of RDF.  Let
>> the author express the intent directly to the UA.  Then if authors
>> want to put in the RDF they can but UA's can continue to blithely
>> ignore everything under a metadata tag as the Specification currently
>> suggests.
> And that is what the current 1.2 draft suggests. Anything inside 
> metadata is still ignorable, but UAs MAY notice that there is some CC 
> data in there and make it available to the user.  And the simplest
> degrees of doing so do not require mucking about with RDF, only a little 
> XML hackery.

    First off if you truly believe that this changes nothing then why
are you fighting to keep the 'MAY'?

    Because we all know in specifications a 'may' is in fact optional
from a conformance point of view but is _strongly_ encouraged.  Put
another way when it comes to managerial 'check box' time this will
appear as:

	'Copyright support?' - yes/no.

    If you are going to 'present' the CC data to the user you must then
parse and understand the CC data (unless you suggest they throw raw
RDF on the screen!).

    Just so people know what this RDF looks like I've attached an 
example, it's not terrible but it's not trivial either (and who
knows what may change in the future), then you have issues about is
it correct etc.


<rdf:RDF xmlns=""
<Work rdf:about="">
<license rdf:resource="" />
<License rdf:about="">
    <requires rdf:resource="" />
    <permits rdf:resource="" />
    <permits rdf:resource="" />
    <permits rdf:resource="" />
    <requires rdf:resource="" />

Received on Monday, 1 December 2003 17:43:03 UTC