A crazy, random idea I had today would be to have an html tag for license. Usually when we access a website there is no possibility of knowing whether certain content is licensed or not - or html is licensed or not.
Partial or final solution
The proposal I have today is to solve the problem of determination and right of content by the html license tag - below is a list of license tags. For example:
option 1: set body or head with license
<!DOCTYPE html>
<html>
<head license-type="GPL-3.0">
<link rel="license" href="GPL-3.0.txt">
<!---
or href="MIT.txt"
or href="Copyright.txt"
...
--->
</head>
<body license="GPL-3.0">
<p>Content licensed with GPL-3.0 license </p>
</body>
</html>
This is definitely not random. In Web 3.0 the different vendors content is mixed into web application with own license requirements. This content is not only comes from 3rd party vendors but also served from different hosts/CDN/repositories. For Declarative Custom Element and Declarative Web Application served from outside, the license data definitely have a sense and would be a part of components acceptance protocol for portals or CMS.
Going further, I would imagine the styling (outline, background, etc. ) based on this tag in DCE on edit mode in visual designers.
To make it more coding-friendly, it worth to be added to own namespace exposed as to HTML as to XML with matching DTD.
XSLT 4 proposed ability to mix namespaces as long as tags are not overlapping, same can be assumed in HTML.
As most of those could have multiple and complex entries, embedding would be needed.
The Declarative approach for those kind of data needs abstract container with section type.
The meta tag is self closing and does not allow to include relative and long content. While it is possible to inject several license(or another) related info using prefix, repeated keys would be clunky cloning
I had a perhaps strange or unique vision is: a document type definition(dtd) is a set of markup declarations that define a document type for an SGML, GML, IBM_Generalized_Markup_Language, SGML, XML, HTML Because a dtd defines the valid building blocks of an XML document. It defines the document structure with a list of validated elements and attributes. A DTD can be declared inline inside an XML document, or as an external. DTD is similar to package.json
We can see this here:
<!--- file license.dtd --->
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE HELLO [
<!ELEMENT HELLO (#PCDATA)>
<!ATTLIST HELLO NAME LICENSE CDATA #REQUIRED>
]>
<HELLO LICENSE="GPL"> Hello text with licensed GPL </HELLO>
and here:
<!-- Imports dtd with license with democdn2 external, license -->
<link rel="license" href="https://democdn1.com/DTD/GPL/3/license.dtd">
or here too:
<!--- another file license.dtd --->
<?xml version="1.0" ?>
<!DOCTYPE hello SYSTEM "contributors.dtd">
<hello> hello licensed with contributors.dtd </hello>
or here too:
<!--- another file license.dtd --->
<?xml version="1.0" ?>
<!DOCTYPE hello SYSTEM "metagroup.dtd">
<hello> hello licensed with metagroup.dtd </hello>
I imagine that our package.json would be a dtd file specifying the areas where a certain content or html element is licensed.
Or… In another case, I imagine that our package.json would be a web-component file specifying the areas where a certain content or html element is licensed.
Each cdn network can specify certain html elements with some license or even each web compoenent within a cdn network must specify certain html elements with some license too, so I realized the use case of dtd and web component as necessary for license
use case here:
<!-- use case 1: Imports dtd with license with democdn2 external, license -->
<link rel="license" href="https://democdn1.com/DTD/GPL/3/license.dtd">
<!-- use case 2: Imports web component with license with democdn2 external, license -->
<link rel="import" href="https://democdn2.com/GPL/3/license">
I am looking into license and other fields from consumer point of view. Same html document could have 0+ licenses itself and web components / WC libraries own ones.
As an application code programmer I need those to be exposed coherently in HTML DOM. XML annotations, comments and other non-dom methods do not fit into usual DOM processing routine, leaving tag-based syntax as most convenient for purpose.
The external and embedded definitions are definitely needed. Each would serve own purpose:
external is reusable and cache-able, embedded easier to process. Ideally embedded and external formats would use same syntax so “if not embedded, load external reference and process in same fashion” would be applicable. Which takes JSON like package.json or webcomponent.json out of equation as the consumption of inline and external would differ.
Just a reminder, the proposal is about declarative syntax, no need to circle back to JSON as a format.
XML-like format would make internal and external preference a matter of same single expression in XPath or JS.
@Anonymous2292900 , You of course can start proposal in scope of WICG. But at this stage there is so little review. Perhaps it worth to prepare the proposal but wait on publishing till mid of January when folks back from holiday break?
As for the help, would be glad to chime in but it would not be much efficient as I have not done the formal W3C proposals yet.
Having XML data island as part of metadata associated either with a HTML document (page) or any of its components would be helpful. Those components with own metadata could be any video, OBJECT, Declarative Custom Element, etc.
Thank you for your help. I’m happy with the idea of the proposal but I don’t think it makes sense, considering that the WICG has a proposal similar to the html by the href.