realize this is a mouthful and why schemas are hard to grok. happy to do a voice/zoom chat for a higher bandwidth chat 😅

no worries, here's a toddler demanding attention so I was away for a moment

So the use case for the namespace is basically two-fold: 1. add structure hints for grand-children 2. show warnings "not conforming to schema" for non-namespaced arbitrary notes This makes sense, thanks for patiently explaining it :). The terminology takes some time to swallow. I wonder if there would be some terms / term sharpening that would make it easier for newcomers? At least the following things come to mind: - "schema" vs "schema file" vs "schema node": I think these are now bundled in a single term "schema", which kind of tripped me a few times - "domain": I think this is the first level after the root, but not sure if it's something more - "domain namespace": I guess this means the second level, if the first level is defined as namespace, not 100% sure though. Also following things come to mind: - Can root-element be defined as a namespace? i.e. have schema for its grand-children? - Could the term "namespace" be changed to "open" (true/false) more clearly pointing out that a schema node is "open for extensions" - Assuming the "domain" denotes some kind of important partition that should be the root for activities like inserting new notes; what if the structure is such that domains make sense only on the second level, i.e. new notes should appear on third level. Would this kind of use case make sense, or is it just a design decision for dendron to support domains on first level only.

> So the use case for the namespace is basically two-fold: > 1. add structure hints for grand-children > 2. show warnings "not conforming to schema" for non-namespaced arbitrary notes yep. one more thing I would add is that it is used by journal/scratch notes in

defaultAddBehavior

> This makes sense, thanks for patiently explaining it :). no problem. thanks for giving me a chance to refine my explanation 🙂

> The terminology takes some time to swallow. I wonder if there would be some terms / term sharpening that would make it easier for newcomers? At least the following things come to mind: > - "schema" vs "schema file" vs "schema node": I think these are now bundled in a single term "schema", which kind of tripped me a few times - yeah, you're right. will update the docs with something like the following: - schema: a taxonomy that describes a given note hierarchy. schemas are stored in schema file next to your notes and made up of schema nodes. - schema file: a yml file that matches the following pattern

*.schema.yml

. it is made from schema nodes - schema node: a single entry in a schema > - "domain": I think this is the first level after the root, but not sure if it's something more - yep, exactly. think of it as the

top level folder

from a traditional file system > - "domain namespace": I guess this means the second level, if the first level is defined as namespace, not 100% sure though. - yeah, it is. not thrilled with this because this is a kludge of sorts. namespaces are a schema concept and can occur at any level of a hierarchy.

domain namespace

is only a thing because i needed it as a

defaultAddBehavior

since most of my domains happen to be namespaces and I would like to keep my journals under the namespace instead of the domain (eg. pro.dendron.journal vs pro.journal)

> - Can root-element be defined as a namespace? i.e. have schema for its grand-children? > - not currently. schemas need a domain to attach to. have been thinking about a

global schema

concept that might fit what you're thinking about > - Could the term "namespace" be changed to "open" (true/false) more clearly pointing out that a schema node is "open for extensions" > - it could. though i'm not sure if that's more obvious than namespace > - Assuming the "domain" denotes some kind of important partition that should be the root for activities like inserting new notes; what if the structure is such that domains make sense only on the second level, i.e. new notes should appear on third level. Would this kind of use case make sense, or is it just a design decision for dendron to support domains on first level only. - domains are meant to be the root of your hierarchies. there's no concept of a

domain

at deeper levels. that being said, i think

domain namespace

is a kludge and would like to support marking arbitrary points in your schema as entry points. this way, you could specify

defaultAddBehavior

in terms of the schema (eg.

schema: ${domain}.{path/to/child})

. thus,

childOfDomainNamespace

can eventually be replaced with something like

${domain}.${namespace}?

> i think domain namespace is a kludge and would like to support marking arbitrary points in your schema as entry points. I like that, I'd even go as far as to consider dropping the concept of domain altogether and just talk about closest/farthest entrypoint. > schemas need a domain to attach to Didn't quite get that one... > open vs. namespace; it could. though i'm not sure if that's more obvious than namespace Yeah, personally I don't need it anymore after understanding the concept. Just thinking about new users, and potentially the ones who have not heard about schemas and namespaces before. What's the background for the "namespace"-term in this context, btw?

> I like that, I'd even go as far as to consider dropping the concept of domain altogether and just talk about closest/farthest entrypoint. yeah, the

domain

concept is probably not required. i use it as short form to mean "the root of this hierarchy". but i suppose

root

will also do and its one less thing to think about. as long as people don't confuse that for

root.md

which is the root of your entire vault. will stew on this 🙂 > Didn't quite get that one... the

root

of a schema tree needs a something to match. the convention is for the root of a

schema tree

to match the root of a

note tree

(aka, its domain) (that being said, you could have a schema whose root matches the pattern

*

) > Yeah, personally I don't need it anymore after understanding the concept. Just thinking about new users, and potentially the ones who have not heard about schemas and namespaces before. What's the background for the "namespace"-term in this context, btw? using namespace in the computer science context (eg. a container of other things) --> https://en.wikipedia.org/wiki/Namespace - eg. my knowledge base has 12 hierarchies vs my knowledge base has 12 domains

yeah, I've used namespaces before e.g. with xml schemas and various programming languages, but somehow the namespace concept in dendron doesn't fit into the same slot in my head. In earlier cases I've typically used it to avoid naming conflicts, however in dendron it somehow seems to open a schema node for augmentation, thus the confusion.

got it. as far as names go, they’re are all subject change. that’s why this is the preview 🙂

think i’m going to create an rfc like issue about names later today and mention what we discussed here

spent again some time today on the scratch note issue; having some hard time on build and debug

thus tried to do a clean pull + install based on instructions

got as far as this

src/topics/markdown/plugins/__tests__/dendronLinksPlugin.spec.ts(6,7): error TS6133: 'processor' is declared but its value is never read.

I think some settings somewhere are now doing strict checks

in general it would be nice to have the following: 1) setup script that performs steps between

npm install

and

watch

, 2) statement to use

dendron.code-workspace

when doing development; now I always forget and end up seeing odd errors 3) instructions which commands should be re-run after repo sync; now I started to get some errors related to some mdast related stuff 4) the watch running parallel might swallow some errors in some cases, e.g. errors from engine-server were sometimes hidden by latter compilation from other packages, don't know what would be the best approach for this

cleaned up the warning. you should be able to build cleanly now. as for the mdast issue, those were new packages i added yesterday for markdown parsing. you can build them by running the bootstrap sequence again

npx lerna bootstrap --scope @dendronhq/common-all  --scope @dendronhq/common-server --scope @dendronhq/engine-server --scope @dendronhq/plugin-core --scope @dendronhq/dendron-cli

and you're right about the parallel runner swallowing errors. going to look into adding a husky hook to catch warnings before committing. will also be updating the dev docs based on your comments

> cleaned up the warning. you should be able to build cleanly now. I might have some setting set somewhere, since it outright just raised an error about this and stopped the build altogether.

for the bootstrap sequence, I think I did that and it still didn't work 🤔

or maybe it was related to that other error

i think you have tighter settings than me somewhere

but yeah, for bootstrap, if that didn't raise an error, i would just check that the packages are also compiled (bootstrap installs dependencies only but ts won't pick it up unless its built)

i usually leave the 'watch' script running perpetually though sometimes if that doesn't work, i will cancel it and run the

build

sequence again

@User when you mentioned dendron overriding your color theme on updates, do you mean the

"workbench.colorTheme"

setting?

@User yes. I have "Default Dark +" set both in User and in Workspace, and updates override the workspace setting.

got it. issue is that we only check your workspace settings for existing values and not your global settings expect to keep your dark theme for today's update 🙂

is it even possible that there's no global setting for color theme? Not sure why you need to check for it)).

when dendron updates, it also tries to upgrade your local workspace settings with the current dendron defaults. it won't try to set a value if you already have a value set

if you have the theme set inside your workspace, dendron shouldn't overwrite it :/