spdx / spdx-3-model Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
I would like to move the extensions
property of elements to its own Extensions
object in a new profile.
This has several advantages:
The examples in the diagram are missing CreationInfo
for every Element except for the top level ones. Is that expected and is there an implicit semantic to propagate this information down to child nodes?
Some time ago we moved creation-related properties from Element to the CreationInformation class because 1) they are related in purpose and 2) it makes Element easier on the eyes. But that raises the question of default values - if Element has a creationInfo property of type CreationInformation, then its value is treated as a single unit, not five or six separate property values. That won't work because the requirement is for each property to have an individual default value that doesn't need to be sent even if another property is not defaulted.
Two potential solutions:
Element
+ SPDXID: IRI
+ name: String [0..1]
+ summary: String [0..1]
+ description: String [0..1]
+ comment: String [0..1]
#include CreationInformation
+ verifiedUsing: IntegrityMethod [0..1]
...
where the #include
macro substitutes the group of properties called CreationInformation into Element, and there is no actual CreationInformation class.
If we did that, I'd shorten Element even more by defining a DescriptiveInformation macro with the summary, description, and comment properties.
Pros of #1: doesn't need any new modeling conventions or tooling support
Cons of #1: Element is bloated
Pros of #2: it's cool
Cons of #2: needs work to invent, macro properties must be de-duplicated (e.g. creationComment)
In SPDX2 we could express a list of excluded files, how is this possible in SPDX3?
Gary's comment from #74:
The idea is we would have a separate verification implementation for packages that would include this information. The work for this hasn't been done.
This has been discussed in the tech team call on 2023-02-28. It is not clear yet whether PackageVerificationCode
will be carried over to SPDX3.
Why is there a element
relation between Payload
and Element
? Why is the element
relation between Collection
and Element
not sufficient?
Further is this element
relation a n-to-m
relation and since everything derives from Payload there are arbitrary element
relations between arbitrary Elements possible, which is even more flexible then the Collection
, that feels wrong.
IBM coined the term "unfriendly" for serializations that use repeated constant property names, and "friendly" where property names directly identify the property. For example, an unfriendly email header would be:
"header": [
{"header_name": "from", "value": "[email protected]"},
{"header_name": "to", "value", "[email protected]"}
]
The friendly alternative uses names to directly identify values:
"header": {
"from": "[email protected]",
"to": "[email protected]"
}
In SPDX this affects the serialization of types such as Hash ("algorithm", "hashValue") and NamespaceMap ("prefix", "namespace"). The logical model is unaffected; this issue concerns only serialization.
The unfriendly serialization of NamespaceMap is:
"namespace": [
{"prefix": "acme", "namespace": "http://sboms.acme.org"}
]
and the friendly version is:
"namespace": {
"acme": "http://sboms.acme.org"
}
Proposal: where repeated constant property names appear in lists of the form {"tag": x, "value": y} pairs, serialize them as object properties {x: y}.
Decision: ?
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
I see that on element SPDXID: IRI
, but not every IRI
is a SPDXID
and thus I wonder if there should be a special datatype with a defined structure. Especially if someone substitutes relations like rootElement
with an IRI
instead of the whole Element
, a definition would be helpful.
(This is very WIP)
Hey,
just some brainstorming, that I am doing in https://github.com/maxhbr/spdx-3-model.compositional. I tried to implement (just for fun) the current state of SPDX3 model 92c25fc multiple times and I failed in the complicated inheritance. Especially when trying to add a second profile it fall apart. I had more success when using the following compositional model (Element is a sealed trait
or Enum
or algebraic datatype
):
Not sure why there is Collection
and Bundle
, looks like they can just be collapsed into one. Was there a discussion on that?
This is part of #74:
Edit: updated after I understood that ExternalPackageReference will be split into two new properties. Some references will convert to ExternalIdentifier, others to ExternalReference. See the migration documentation for a conversion guideline.
There remain two problems when the category
is OTHER
:
type
can be String-valued. Should this then be converted to SPDX3 ExternalIdentifierType.other
or ExternalReferenceType.other
?locator
can be an arbitrary String (without spaces) in SPDX2, but the SPDX3 ExternalReference.locator
must be a URI. ExternalIdentifier.identifier
would be a String, but can we be sure that the SPDX2 reference of category OTHER
is actually an identifier?Why is there Actor
? Feels like something that could be satisfied by Identity
or at least very closely matches that?
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Below are the items raised in the August 30, 2022 tech call along with pointers to any previous discussions or decisions directly related to the item.
The table has the following columns:
Class
The model class the item relates to, or Overview
if it is a general item pertaining to all classesItem
The punch list item - text taken verbatim from the minutes as of 31 August 2022Cat.
A Category indicating if this item has been previously discussed. The category is one of:
NPD
- Not previously discussed - no evidence was found in prior meetings of this item being discussedDD
- Discussed and decided - there are minutes or notes in a GitHub issue that this item was discussed and a decision madeDND
- Discussed and not decided - There are minutes or issue notes where this was discussed, but no clear decision was recorded in the minutesClass | Item | Cat. | References | Status |
---|---|---|---|---|
Snippet | Snippet is line range and byte range. Yes. Punch: Document beginning & end of snippet in model. | DND | Issue #11 | Resolved, added line and byte ranges to model. Byte range takes precedence if in conflict. |
Snippet | Discuss and determine if we should add a "data class" and relationship between data class, file and snippet. Ping Alexios. We may already have a relationtype suitable. Content of a file is one object, Metadata of a file is another object. | NPD | Although this was described as a previous suggestion on the call, I could not find mention in prior meeting minutes | Not a blocker for 3.0, Sebastian and Jeff are working on related proposals. |
Snippet | clarify location cardinality in model | DND | Issue #11 | Resolved. Keeping single location for 3.0, content proposal may amend. |
File | Clarify definition of Package and File and how they relate to each other (including if download location makes sense for a file) | NPD | Lots of discussions on package download location, but no evidence of file download location being discussed | Resolved. These are properties on Package but available via ExternalReferences for other artifacts. |
Package | Revisit cardinality of Download location. 0..* | DD | Decision documented in 2021-10-05.md | Resolved. Primary attached to Package, additional can be added with ExternalReferences. |
Package | Revisit cardinality of Home Page (depends on purpose - ie. marketing, developer) | DND | Cardinality not specifically addressed, but discussed on issue #13, 2022-03-01.md, 2021-12-07.md, 2020-10-13.md | Resolved. Primary attached to Package, additional can be added with ExternalReferences. |
Package | Clause 7 fields reviewed for coverage. Some should 2.3 become elements? or more fields in the Package class? | DND | Several discussions on individual fields found, but not as an entire group | Open issue. |
Package | Should Package URL be a property on package? | DND | Discussed on 2021-11-09.md - line 74 looks like a decision | Resolved. Added as a property on Package. |
Artifact | Should Artifact URI be moved back into Artifact class. (one form of an external identifier) | DD? | 2020-10-13.md,2020-09-14.md,2020-10-13.md - decision to make property? 2020-11-09.md | Resolved. Decided not to add this since no universal URI for all artifact types. Added content identifiers to File and Snippet to resolve one of the needs for this. |
Artifact | Should location be added to Artifact or at the Package/File/Snippet level? | DND | 2022-08-16.md | Resolved. Did not add property but available via ExternalReferences. |
Element | Should external locator and external identifier be called out in Element? | DND | 2022-08-16.md | Resolved. ExternalIdentifiers on element meets this need. |
Element | External Identifiers need to be better defined | DND | Note that we've have several discussions on external identifiers - to many to list here | Pending. Need to document in spec text but concept is defined (identifier from an external system that uniquely identifies the subject of the element). |
Element | Gain consensus and clarity on type of extension element. (clarify - Map<IRI, any> Structure or dictionary map? | DND | Discussed in 2022-03-22.md and marked as closed but specific type was not documented. Also discussed in 2021-12-07.md, 2021-04-20.md, 2021-03-02.md, and 2021-02-23.md | Pending. There are still some active concerns about the existence of this concept. |
Element | Assess if data model proposal (Alexios) works with VerifiedUsing (example SPDX document element) | See above | Data model proposal under snippet | |
Element | Clarify if VerifiedUsing refers to integrity of the 'thing' described by an Element, or the integrity of the Element data itself (its canonical representation)? Capture and enable both with separate "targetVerifiedUsing" and "elementVerifiedUsing properties? targetVerifiedUsing would go in Artifact, not Element. | DND | Partial decision in 2021-11-09.md, does not look like it was discussed in 2021-11-16.md | Resolved. verifiedUsing is how to verify the subject of the element. Non-blocking for 3.0: Canonicalization WG to propose what is needed for canonicalization. |
Element | On ExternalReference and ExternalIdentifier indended to be abstract and if so, how does it work | NPD | Resolved. Not abstract. | |
Element | Provide a complete list of annotation types. | DD | Decision documented in 2022-03-29.md | Resolved. List updated. |
Enumerations | Need to be made complete with values pulling forward from 2.3 | ? | more of an action than a decision | Resolved? Please verify. |
Enumerations | Should they be closed, or allow folks to add things. (Folks can always add other things to their software, but can those things claim to be SPDX-conforming?) | NPD | Could only find one discussion on enumerations for profiles | Resolved. They are closed but software wanting to maintain forward compatibility should expect new values. |
Actor | should Actor have it's own identifier property? See ArtifactURI. | DD? | Line 70 in 2022-04-05.md appears to be a decision | Pending. Ongoing discussion about identities. |
Relationship | what are the use-cases for relationship cardinalities (from+to) and directions | DD? | Discussed in issue #5 | Documentation? |
Relationship | Revisit cardinality of relationshipCompleteness. (In context of serialization. ) Default, optional are conflicting. | NPD | I couldn't find this specific discussion | Resolved. Logically it must be present, but there is a common default value for serializations and they are recommended to make it optional. |
Relationship | Articulate all the Enumerated relationship types for 3.0 | ?? | More of an action than a decision | Resolved? Please verify. |
Checksum | Enumeration: Consider adding "OTHER" | NPD | Resolved. Added. | |
Overview | Create an spreadsheet Review 2.3 and 3.0 | ?? | More of an action than a decision | Pending. |
Overview | Do we want to restrict Enumerations or allow extensions? Historical we've kept it restricted for Consumer benefit. | NPD | Same as enumerations issue listed above | Resolved. Duplicate. |
Overview | Should Profiles or closed, or enable extending definitions. | DD | Discussed and decided in 2021-03-30.md, 2021-04-06.md, 2021-04-20.md, 2021-04-27.md, | Resolved. |
Overview | Anything in 2.3 we need to justify why we deprecate. Already depricated, we don't need to revisit. | ?? | More of an action | Pending. |
Overview | How do we handle optional fields with default values in model? Should optionality be part of data model, not in information model? Can you answer the question is this complete at logical model level? Do we want to have consistent approach across all fields. When not present stating default value, etc. | NPD | similar to other punch list items above | Resolved. Duplicate. |
The element "profile" property is a list of profile names, e.g., "core", "software", etc.
The conventional way of serializing a list of string values is as a list:
"profile": ["core", "software"]
It has been suggested to instead require all list items to be serialized as objects with repeated constant property names:
"profile": [
{
"name": "core"
},
{
"name": "software"
}
]
Proposal: Serialize lists with their actual values (e.g., IRIs, enumerations such as profile name, SoftwarePurpose, etc. rather than injecting an artificial object wrapper around those values.
Rationale: an object wrapper makes serialized data both more verbose and more difficult to read. But more importantly, the extra data provides no information - the receiver knows nothing more after seeing it than it does without seeing it. Proof: a receiver, after receiving the native list, has everything it needs to locally transform it into the list of objects if that format is needed for some reason.
Decision: ?
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Part of #74:
SPDX 2 fileType
will be converted to contentType
. But contrary to contentType
, fileType
is not restricted to a single value, thus different fileType
s might call for different contentType
s, which would be problematic.
This topic has been discussed in the tech team call on 2023-02-21.
An example document "from the wild" with multiple file types per file can be found here.
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
as mentioned in #42, the examples in the diagram contain "software"
profile elements (e.g. SBOM
) but do not list it under profiles
in their creation info. This probably should be fixed.
Ping @iamwillbar
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
While the logical model is intended to be independent of serialization, serialized data needs to be defined in a way that can be hashed consistently. For example: Class files define properties:
SPDX-License-Identifier: Community-Spec-1.0
# Annotation
## Summary
An assertion made in relation to one or more elements.
## Description
An Annotation is an assertion made in relation to one or more elements.
## Metadata
- name: Annotation
- SubclassOf: Element
- Instantiability: Concrete
## Properties
- annotationType
- type: AnnotationTypeVocab
- minCount: 1
- maxCount: 1
- contentType
- type: MediaType
- statement
- type: xsd:string
- minCount: 0
- maxCount: 1
- subject
- type: Element
- minCount: 1
- maxCount: 1
The properties logically have no ordering, but when serializing the order matters:
{ "subject": "http://acme.com/sboms/1948294/package59", "annotationType": "REVIEW", "statement": "Awesome!" }
is a different serialized value than:
{"statement": "Awesome!", "annotationType": "REVIEW", "subject": "http://acme.com/sboms/1948294/package59" }
and a different value than:
[ "http://acme.com/sboms/1948294/package59", "REVIEW", "Awesome!" ]
even though all are equivalent JSON serializations of the identical annotation.
PROPOSAL:
Add an id field to all Property definitions to enable the model files to be the single source of truth for both the logical model and the information/serialization model:
## Properties
- subject
- type: Element
- minCount: 1
- maxCount: 1
- id: 1
- link: true
- annotationType
- type: AnnotationTypeVocab
- minCount: 1
- maxCount: 1
- id: 2
- statement
- type: xsd:string
- minCount: 0
- maxCount: 1
- id: 3
- contentType
- type: MediaType
- id: 4
The id field serves several purposes in a serialization model:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Hey, I have looked at the following example taken from the current png and I have a question related to it, regarding "one does not need to support every profile and just looses information that is not relevant".
{
"@type": "SBOM",
"@id": "urn:spdx.dev:null-sbom",
"creationInfo": {
"specVersion": "3.0",
"created": "2022-05-02T20:28:00.000Z",
"profile": ["core","software"],
"dataLicense": "CC0",
"createdBy": ["urn:spdx.dev:iamwillbar"]
},
"rootElements": ["urn:spdx.dev:spdx-tools-3.0.1"],
"externalMap": [ <...> ],
"elements": [ <...> ]
}
For this example lets assume that I do not have support for software profile. Since SBOM is basically a BOM I would assume that I still should be able to parse it (despite loosing some information, that is not relevant for me).
But how do I know that it is basically a BOM, the JSON does not contain that information?
(A rather ugly workaround would be to have something like "@type": "SBOM:BOM:Bundle:Collection:Element"
in the serialization.)
This scenario came up in the Asia SPDX tech call on Jan 9, 2023.
An entity which is in the middle of a software supply chain receives an SPDX document and wishes to add profile information (e.g. the Build profile) before passing the information on to downstream consumers.
In SPDX 2.X, you would produce an SPDX Document which has an AMENDS
relationship to the supplied SPDX document.
Since each element has creator information and can be independent of the Document, I would like to document the best practice for this scenario.
A proposal would be that each Element (be it a Package, SBOM, File, etc.) would be updated in the new document with the Profile information. The Profile would also be added to the Creator information for the element. An AMENDS
relationship would be added from the new Element to the previous Element using the ExternalMap to reference the previous Element.
There are a couple of downsides to the above proposal:
I'm open to any other proposals or variations on a theme.
Below is an example:
Original Supplier element:
{
...
"elements": [
"@type": "Package",
"@id": "urn:originalsupplier.org:packagea#elementid",
"creationInfo": { ... "profile": ["core", "software"] ...
"name": "myPackage"
...
],
...
}
Intermediate supplier element
{
...
"externalMap": [{"elementId": "urn:originalsupplier.org:packagea#elementid"}],
"elements": [
"@type": "Package",
"@id": "urn:intermediateSupplier.org:packagea#uniqueid2",
"creationInfo": { ... "profile": ["core", "software", "build"] ...
"name": "myPackage",
"buildDate": "2022-12-13T18:36:37.793Z",
...
],
...
}
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punchlist of problems we are currently facing when converting SPDX2 to SPDX3. See also this spreadsheet for an overview of the current state.
Please feel free to comment on any of the points below. Small remarks can go right here in this issue, but if you want to start an in-depth discussion on any of the points, please open and link a new issue (edit this post) to keep this issue comprehensive.
CreationInformation properties:
File properties:
Package properties:
Relationship properties:
to
property of the SPDX3 relationship, which is an Element
. But relatedSpdxElement
can also take the values NONE
and NOASSERTION
. How should these be converted to an Element
?completeness
relationSnippet properties:
contains
relationship from the containing file to the contained snippet?This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
NOTE: We didn't discuss project, tool, organization, person because they are dependent on answers to the above.
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
In the SPDX 2.X spec, there are several fields which accept a value of NONE
and NOASSERTION
which have specific semantic meaning along with either a text or a class.
This is defined in RDF as a superclass restriction - you can find an example for SPDX Item in the License Concluded
property. This may not be the cleanest approach since we're mixing individual values with other types (e.g. xsd:string
) and the reasoning is rather clunky IMHO.
@swinslow is proposing having an abstract class for each of the properties where the values can include the NONE
and NOASSERTION
values which may yield a slightly different RDF model.
There may also be other alternatives.
Whichever approach we take, we should probably be consistent.
Related to issue #71
@sbarnum @davaya @zvr - Interested in any thoughts you have on this issue.
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Based on snippet punch list discussion:
Since "verifiedUsing" does not apply to most elements, move it from Element to Artifact, removing confusion that it might apply to metadata. SpdxDocument has content; it must either extend Artifact or have a "verifiedUsing" property.
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Currently the .png shows the ENUM values of DependencyScope
:
noAssertion [default]
static
dynamic
tool
other
I think this should not include noAssertion
and that instead there should be a general concept of optional values. And, if an optional value is not present, that can be serialized as NOASSERTION
or null
or ...
Further, the default value and cardinallity of an enum should be decided by the user and not by the enum.
(It might also be an issue, that some programming languages have global namespaces for enum vaules and noAssertion
is appearing in multiple ones)
The model defines a Payload interface, indicating that it can include a single serialized element, as well as multiple elements serialized together. The model diagram includes a few examples, but is missing an example of an individual Sbom element.
This is an example of the individual SBOM element shown on the diagram without nesting other element content:
{
"id": "urn:spdx.dev:null-sbom",
"type": {
"sbom": {
"element": [
"urn:spdx.dev:iamwillbar",
"urn:spdx.dev:spdx-tools-3.0.1",
"urn:spdx.dev:project",
"urn:spdx.dev:doc"
],
"import": [
{
"externalId": "urn:spdx.dev:project",
"verifiedUsing": {"hash": {"sha256": "14a657a7118a333cc1fdc6af05071a59cda067fd11130d4ee5d6d47c26e7863f"}},
"locationHint": "https://spdx.dev/projects/v1.0.json"
},
{
"externalId": "urn:spdx.dev:doc",
"verifiedUsing": {"hash": {"sha256": "14a657a7118a333cc1fdc6af05071a59cda067fd11130d4ee5d6d47c26e7863f"}},
"locationHint": "https://spdx.dev/docs/v1.0.json"
}
]
}
},
"creator": ["urn:spdx.dev:iamwillbar"],
"created": "2022-05-02T20:28:00.000Z",
"specVersion": "3.0",
"profile": ["core", "software"],
"dataLicense": "CC0-1.0"
}
Topics for discussion include:
(I know that this is a serialization question. But we are right now acting under the assumption that serialization can answer this question so I think it is fair to ask it already)
Hey, I came up with the following example:
lets say you have a SPDXDocument called SPDXDocument
containing a SBOM called SBOM
containing a Package called Package
.
This can be encoded either completely inlined or the Package
can be pulled one level up and just be referenced in the SBOM
element. And both are parsed to the same internal representation.
So, in some kind of pseudo code it could look like:
SPDXDocument {
SBOM {
Package
}
}
or
SPDXDocument {
SBOM {
PackageRef
},
Package
}
Now, my question is the following:
SPDXDocument
and SBOM
would have different creationInfos, which of these would be inferred to Package
?And as a potential follow up / equivalent question:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
Part of #74:
Relationship
to a file? packageFileName
may also point to a folder, though.Gary's comment from #74:
We were thinking of using a relationship. If it is a folder, then we would probably create a separate "package" definition to represent the folder? The folder scenario is one I have not thought through and probably deserves more discussion.
This has been discussed in the tech team call on 2023-02-21.
This has been discussed in the tech team call on 2023-03-07:
Gary's migration document describes the conversion process.
Open issue is still the case that packageFileName
may also point to a folder.
in 92c25fc one has the following cyclic dependency which is annoying when implementing:
Element
definition depends on the definition of CreationInformation
CreationInformation
contains a createdBy
field of type Actor
and thus depends on its definitionActor
itself derives from Element
so it is dependent on its definitionThis causes a cyclic dependency between implementing modules which is really bad in some programming languages and at least annoying in others.
Part of #74:
There is no integrity profile to take the place of requiring checksums for files. Some uses of filesAnalyzed indicate that a certain level of tooling was applied to the source. We would lose this information if this field is removed.
Gary's comment from #74:
I wonder if the build profile would service this purpose?
Brandon Lum's comment from #74:
The build profile has some established relationships on the files themselves. So the information would be encodable by the build profile relationships. However, that is just the ability to express the relationship. I'd be curious to discuss what the integrity story would look like (as it ties into verification). I think that's probably something to discuss... since with the build profile the granularity of identities may be more granular and harder to manage.
..and how do I determine them correctly? So for example a SPDXDocument
is a Subclass of Bundle
which is Subclass of SpdxCollection
. A SpdxCollection
has at least one element
and at least one rootElement
. If I now try to migrate a document
from spdx 2.3 into a SpdxDocument
in spdx 3.0, I would assume that Packages, Files, Snippets, Relationships
and Annotations
would be collected in the List of element
but what is the rootElement
in that case?
A few errors came up when parsing the Core files:
Classes / Document / Properties / externalMap / type; ExternalMap should be colon
Classes / Extension - has no Properties section
Classes / IntegrityMethod - has no Metadata or Properties sections
Classes / Package / Metadata - subclass is not a list item
Classes / Package - has no Properties section
Classes / PublicKey - has no Properties
Vocabularies / HashAlgorithmVocab - description section should be capitalized
Some of these are easily-fixed typos. Others require the model itself to be developed before the template can include the information. And Classes/Agent and related elements don't exist in the current model, indicating the template should be updated.
This is a punch list of open questions from the 2021-12-14 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.