encoding/jsonschema: default values should be ignored when generating schemas

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.0.0-20240930133809-f0c77ed99d74

go version go1.23.0
      -buildmode exe
       -compiler gc
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 1
          GOARCH arm64
            GOOS linux
         GOARM64 v8.0
             vcs git
    vcs.revision f0c77ed99d74c1441ec8b18588da9998d0327fe0
        vcs.time 2024-09-30T13:38:09Z
    vcs.modified false
cue.lang.version v0.11.0

Does this issue reproduce with the latest release?

n/a - tested with tip.

What did you do?

exec cue import -p x -l '#schema:' jsonschema: schema.json
exec cue export .
cmp stdout stdout.golden

-- schema.json --
{
    "type": "object",
    "title": "CUE",
    "properties": {
        "p": {
            "type": "boolean",
            "default": true
        }
    }
}

-- data.cue --
package x

s: #schema

-- stdout.golden --
{
    "s": {
        "p" : true
    }
}

What did you expect to see?

Passing test.

What did you see instead?

> exec cue import -p x -l '#schema:' jsonschema: schema.json
> exec cue export .
[stdout]
{
    "s": {}
}
> cmp stdout stdout.golden
diff stdout stdout.golden
--- stdout
+++ stdout.golden
@@ -1,3 +1,5 @@
 {
-    "s": {}
+    "s": {
+        "p" : true
+    }
 }

FAIL: /tmp/testscript4054715971/repro.txtar/script.txtar:3: stdout and stdout.golden differ

[rogpeppe]

In the JSON Schema documentation, it says:

The default keyword specifies a default value. This value is not used to fill in missing values during the validation process.

That says to me that the bug here is not that we are generating optional fields that include default values, but that we are including default values in the schema at all. I think that we should probably only generate pure schema values (no regular fields, no default values) from JSON Schema, at least for now. In the future, we can have the option to generate a template value that does include regular fields and defaults, but the current mixed approach seems somewhat wrong to me.

I'll retitle this issue accordingly.