5 ms·

Comparing {mark} to XML, it doesn't seem to support namespaces which makes the claim to be extensible somewhat dubious. How am I supposed to add custom objects

Comparing {mark} to XML, it doesn't seem to support namespaces which makes the claim to be extensible somewhat dubious. How am I supposed to add custom objects without risking name clashes? Namespaces also make XML kind of fully typed without being tied to a single programming language. Another strength of XML is support for mixed content which seems rather awkward in {mark}. The following <p>Some <b>bold</b> text</p> apparently needs to written as {p 'Some' {b 'bold'} 'text'} It would be more honest to mark support for mixed content as "verbose" in the feature table. Besides, the name {mark} seems like a bad idea. How could you find relevant results when searching for {mark} using a search engine?

mgr86 9y ago
it also "...does not have all the legacy things like DTD." Ok sure, but does it have schematron,rng, or some sort of validation? How about transformations? Xpath?
- henryluo 9y ago
  Yes, I explicitly cut out DTD. I'm planning to developed a schema language for Mark, improving on prior art like XML Schema, JSON Schema, etc. There's already a transformation library - Mark Template (https://github.com/henry-luo/mark-template https://github.com/henry-luo/mark-template) in beta release. Mark at the moment supports CSS selector. I'm also thinking about a new Mark-specific selector. Mark is very new. A lot to be done!
  - stephen 9y ago
    I'm enough of a type-safety bigot that I would have started with schema-first, as I want schemas for all the things. :-) FWIW, I would suggest avoiding the (IMO) mistake of using your markup language for the schema. E.g. like json-schemas where we need a "properties" map, "type": "string" (how many times do I have to type "type"), all sorts of syntactical overhead. Personally, I think IDLs are much cleaner, as you can design a purpose-specific grammar. More work up front, and you don't get a parser for free, but again personally I think it's more pleasant in the long-run for developers to read and write. Granted, not sure how that jives with your lisp/etc. way of thinking, but my two cents. Good luck!
henryluo 9y ago
Current Mark design does not enforce a namespace standard. Namespace can be easily captured in Mark, e.g. {'ns:elmt' 'xml:attr':'value' ...} XML Namespace seems to have a lot issues, thus Mark does not want to enforce something exactly following it. Namespace in Mark, currently, is left upto the application user to define it. We might be able to come up with a better way to define namespace. As for the name, you can just use Mark. I use '{mark}' as an alternative name, to make it more graphical, more impressive.
- specialist 9y ago
  Please don't. XML Namespaces is syntactic vinegar. Less is more.
Turing_Machine 9y ago
Hmm... while I'm not seeing any great advantage for {mark}, both of these appear to be 28 characters long. How is one more "verbose" than the other?
- Finnucane 9y ago
  I think 'less verbose' just means 'no end tags'. Which I guess is great if you don't mind a long string of brackets at the end of your document. While it would be cool to have something that was like JSON but could deal with complex documents, I also don't see how this is a huge improvement over XML.

mgr86 9y ago

it also "...does not have all the legacy things like DTD." Ok sure, but does it have schematron,rng, or some sort of validation? How about transformations? Xpath?

henryluo 9y ago
Yes, I explicitly cut out DTD. I'm planning to developed a schema language for Mark, improving on prior art like XML Schema, JSON Schema, etc. There's already a transformation library - Mark Template (https://github.com/henry-luo/mark-template https://github.com/henry-luo/mark-template) in beta release. Mark at the moment supports CSS selector. I'm also thinking about a new Mark-specific selector. Mark is very new. A lot to be done!
- stephen 9y ago
  I'm enough of a type-safety bigot that I would have started with schema-first, as I want schemas for all the things. :-) FWIW, I would suggest avoiding the (IMO) mistake of using your markup language for the schema. E.g. like json-schemas where we need a "properties" map, "type": "string" (how many times do I have to type "type"), all sorts of syntactical overhead. Personally, I think IDLs are much cleaner, as you can design a purpose-specific grammar. More work up front, and you don't get a parser for free, but again personally I think it's more pleasant in the long-run for developers to read and write. Granted, not sure how that jives with your lisp/etc. way of thinking, but my two cents. Good luck!

henryluo 9y ago

Current Mark design does not enforce a namespace standard. Namespace can be easily captured in Mark, e.g. {'ns:elmt' 'xml:attr':'value' ...} XML Namespace seems to have a lot issues, thus Mark does not want to enforce something exactly following it. Namespace in Mark, currently, is left upto the application user to define it. We might be able to come up with a better way to define namespace. As for the name, you can just use Mark. I use '{mark}' as an alternative name, to make it more graphical, more impressive.

specialist 9y ago
Please don't. XML Namespaces is syntactic vinegar. Less is more.

Turing_Machine 9y ago

Hmm... while I'm not seeing any great advantage for {mark}, both of these appear to be 28 characters long. How is one more "verbose" than the other?

Finnucane 9y ago
I think 'less verbose' just means 'no end tags'. Which I guess is great if you don't mind a long string of brackets at the end of your document. While it would be cool to have something that was like JSON but could deal with complex documents, I also don't see how this is a huge improvement over XML.