> you can use them when you have lots of notes under a hierarchy and want to enforce some sort of consistency yep, for this case I'm thinking what is the benefit of the namespace schema for me, as the user. Since by default the namespace allows anything there, it lacks the consistency (only patterns would have some)

namespaces are a bit better than not having anything

since they match

{namespace}.*

, it's better than the glob equivalent of

**/*

which would match not just the child but all children

and while a namespace can be arbitrary, you can still have a well defined structure under a namespace

eg. my project schema

yml
version: 1
imports:
  - cli
  - _cook
  - lang
schemas: 
- id: p
  desc: dev project
  parent: root
  children:
    - lang.operator
    - cli.cli
    - concepts
    - topic
    - config
    - debug
    - qa
    - design
    - internal
    - lifecycle
    - quickstart
    - changelog
    - _cook.cook
    - issues
    - lang.flow
- id: design
- id: issues
- id: config
- id: concepts
- id: topic
  data:
    namespace: true
- id: internal
  desc: Explanation of how code works
- id: lifecycle
- id: quickstart
- id: concepts
- id: debug
- id: qa
- id: changelog
  template:
    id: p.template
    type: note

i use this for software projects (eg. dendron). while the project names are arbitrary, i do have a defined hierarchy for what I expect to be under the project namespace

hmm, what does the matching note hiearchy look like? I was expecting "p" to be namespace

also in this example topic has data attribute and namespace is there?

the

data attribute

is a leftover from pre v1 schema. it's still valid but today, you would just do

namespace: true

hmm, so this would imply structure like p.topic.dendron ? I was expecting structure like p.dendron.design

topic is a child of dendron. so this would match

p.dendron.topic.*

by default, a schema will inherit the pattern prefix of its parent

since

topic

is a child of

project

, the pattern to match topic is the pattern for project

p.*

+ the pattern for topic

t.*

shouldn't "p" be a namespace?

since it allows e.g. dendron below it?

opps, it is. i was correcting the

data: namespace

thing before pasting and removed the whole thing 😅

ok, in this example, why namespace is assigned for "topic"? What would happen if it wouldn't be a namespace?

the reason is because i use topic as a junk drawer for stuff that might differ from project by project

eg. see topics under dendron

sure, but since notes can be added anywhere despite of the schema, I guess any sub-node can be also a junk drawer?

so is there some benefit of explicitly stating that

vscode is also a

project

in my knowledge base. the topics under vscode are the following

> > so is there some benefit of explicitly stating that > @User the benefit is of having it recognized by the schema

so this is similar to typescript - you can compile your typescript code into javascript even if the types don't match (depending on your

tsconfig

). types help make your projects maintainable, especially as they grow

currently, the only thing dendron will do is show you an indicator if your schema doesn't match

in the future, we'll have a strict mode where we will actually prevent you from creating notes that don't match your schema

schemas at the end of the day help you construct consistent hierarchies for your notes. consistent hierarchies alleviate the cognitive overhead of needing to understand and track N things where N can be very big. instead, you can construct a single schema that encompasses the common areas of all N things

this allows you to quickly reference anything within your hierarchy because they all have the same shape. for me, it also helps with understanding a topic - i find my schema for a domain tends to reflect my mental model for said domain as well

eg. I'm using nodejs and need to access a file. i have no idea what the builtin/recommended library for file access is. instead of having to dig up

fs-extra

or

fs

, i can navigate to

l.node.file

and see my notes on the best way to work with files

you can replace

node

with any other programming language. now i have a general way of referencing file access for all languages without needing to remember the specific implementation detail of any of them