4 ms·

RSS/Atom is being slowly killed. XHTML was replaced by a pile or junk that can only be parsed by a single parser. HTML in general became a rendering layer for e

RSS/Atom is being slowly killed. XHTML was replaced by a pile or junk that can only be parsed by a single parser. HTML in general became a rendering layer for executable JavaScript. After years of doing integrations, I've seen one(!) HATEAOS web service and it's being replaced by GraphQL right now. I like the idea of having semantic content, but it is suffocating under the weight of all the overcomplicated designed-by-committee abstractions and formats. In fact, the real web that we're using is becoming less and less semantic every year. I wish someone re-standardized XML without all the complicated edge case garbage and with better handling of namespaces. So it would actually get used for documents again. JSON is not a good document format, and it seems everyone is busy re-inventing XML in JSON right now. Let's say I want to define my own concept and put it on a web page. Is there even an "official" way to do it right now, without namespaces in HTML5? Theoretical example: <html> <head> <concept tag="computer-game" guid="c1a3e0cb-5872-4e5a-8dce-b8afc00772db" /> <concept attribute="year-published" guid="ba073188-8bd6-47a7-9065-eb55c4a8b908" /> </head> <body> <computer-game year-published="1993">Doom</computer-game> </body> </html> Simple, isn't it? I'm not aware of anything of this sort.

faleidel 8y ago
It's possible to define custom HTML tag in javascript, but I don't think that is what you want. https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/define https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...
- gambler 8y ago
  Indeed. It could be useful for rendering custom tags, but the problem with semantic content is that there needs to be an entry point somewhere. No matter how I think about it, it seems that at some level there always needs to be a way to say "this piece of data is officially ba073188-8bd6-47a7-9065-eb55c4a8b908 (year of publishing)". Which means that whenever you see another ba073188-8bd6-47a7-9065-eb55c4a8b908, you and all your tools know the data refers to the same kind of thing. Everything else can be bootstrapped. XML solved this through namespaces + URLs. IMO, it was a cludgy and inelegant solution with weird syntax and unnecessary levels of abstraction, but at least it was something.
zozbot123 8y ago
> Let's say I want to define my own concept and put it on a web page. Is there even an "official" way to do it right now What's wrong with Microdata? As in https://en.wikipedia.org/wiki/Microdata_(HTML) https://en.wikipedia.org/wiki/Microdata_(HTML) It can interoperate with RDF and JSON-LD.
- gambler 8y ago
  First time I hear about it. Let's see. It seems to aim at roughly the same problem, but god, they've managed to design something even uglier and more verbose than XML namespaces. Still requires to use valid URLs instead of GUIds. Still forces you to use external names in your markup. Sigh. One hard limitation I see is that unlike namespaces it doesn't deal with HTML attributes, so you can't just annotate the same tag with unrelated semantics. It also makes assumptions about document structure (item properties are nested inside an item). Semantics and structure should not be complected. This will create innumerable issues when doing logic in code or writing CSS queries. Why does this have to be so ugly and complicated? All we really need is a way to associate data with globally unique identifiers. This gives us semantics. A single layer of indirection (mapping GUIDs to local names of your choice) would allow us to be concise and descriptive in our markup, while avoiding naming conflicts. No matter how much W3C hates it, people are extending HTML with custom tags and attributes. (ng-whatever, for example.) Having no support for providing semantics for such things is pretty ridiculous.
  - zozbot123 8y ago
    > Still requires to use valid URLs instead of GUIds. Not sure why you would want to do this, but AIUI you can use any URI for a namespace (not just URL), including a UUID via the `urn:uuid:c1a3e0cb-5872-4e5a-8dce-b8afc00772db` syntax.
    - titanix2 8y ago
      You can but most of the time, especially with Linked Data, an URL is required. And sometime even a dereferencable one. So you have this weird situation where you never really know if an URL is "semantic" (just a string actually) or can be accessed. Also having a dependency on the DNS system is a bad idea in my opinion. It's really clear when you read 2 years old semantic web paper and every link is broken. I agree with gambler that GUID + local names is a better solution, and I use that in my research.
deleted 8y ago
[deleted]
tannhaeuser 8y ago
To answer your question, you can use HTML+RDFa to annotate any element with semantic info, or simply use meta-links (in the HTML head) for per-page metadata. W3C's semantic web is a lost cause, though, as is XHTML. I don't know why the paper speaks about "the first 20 years", as there's been zero activity for years and I think the semweb charters have been closed years ago. If you're interested in document engineering based on real and practical standards, I'd suggest looking into ISO SGML (superset of XML and HTML) and maybe ISO Topic Maps (with Tolog/ISO Prolog as query language).
iseeyoubydesign 8y ago
I have your answer and you are not going to like it. No matter how good an idea is its not picked up and proliferated unless big money is behind it. You got this nice library , great api. But company x doesnt use it, company x uses their library with their tools. Company x is hiring. So we learn company x tools. Think of every popular and unpopular frontend lib and ask yourself why its popular. jQuery is the only thing that comes to mind without a huge player, it just established itself at the right time.
henryluo 8y ago
I've come up with a new notation Mark (http://marknotation.org/ http://marknotation.org/), to address some of issues faced with JSON and XML. It keeps the simplicity of JSON, and is able to support mixed content at the same time. At the moment, it leaves out namespace to the application. Your sample in Mark would look like: {html {head {concept tag:computer-game guid:"c1a3e0cb-5872-4e5a-8dce-b8afc00772db"} {concept attribute:year-published guid:"ba073188-8bd6-47a7-9065-eb55c4a8b908"} } {body {computer-game year-published:1993 "Doom"} } }
- gambler 8y ago
  Looks pretty good. Not sure how I feel about including JSON as type of embedded content, though. I've used something vaguely similar in the distant past, but it was strictly internal for my hobby projects and mostly resembled lisp with square brackets. It was way more primitive, but the parser (lexer, really) fit into two blocks of code. All the fancy stuff was done within DOM.

faleidel 8y ago

It's possible to define custom HTML tag in javascript, but I don't think that is what you want. https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/define https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...

gambler 8y ago
Indeed. It could be useful for rendering custom tags, but the problem with semantic content is that there needs to be an entry point somewhere. No matter how I think about it, it seems that at some level there always needs to be a way to say "this piece of data is officially ba073188-8bd6-47a7-9065-eb55c4a8b908 (year of publishing)". Which means that whenever you see another ba073188-8bd6-47a7-9065-eb55c4a8b908, you and all your tools know the data refers to the same kind of thing. Everything else can be bootstrapped. XML solved this through namespaces + URLs. IMO, it was a cludgy and inelegant solution with weird syntax and unnecessary levels of abstraction, but at least it was something.

zozbot123 8y ago

> Let's say I want to define my own concept and put it on a web page. Is there even an "official" way to do it right now What's wrong with Microdata? As in https://en.wikipedia.org/wiki/Microdata_(HTML) https://en.wikipedia.org/wiki/Microdata_(HTML) It can interoperate with RDF and JSON-LD.

gambler 8y ago
First time I hear about it. Let's see. It seems to aim at roughly the same problem, but god, they've managed to design something even uglier and more verbose than XML namespaces. Still requires to use valid URLs instead of GUIds. Still forces you to use external names in your markup. Sigh. One hard limitation I see is that unlike namespaces it doesn't deal with HTML attributes, so you can't just annotate the same tag with unrelated semantics. It also makes assumptions about document structure (item properties are nested inside an item). Semantics and structure should not be complected. This will create innumerable issues when doing logic in code or writing CSS queries. Why does this have to be so ugly and complicated? All we really need is a way to associate data with globally unique identifiers. This gives us semantics. A single layer of indirection (mapping GUIDs to local names of your choice) would allow us to be concise and descriptive in our markup, while avoiding naming conflicts. No matter how much W3C hates it, people are extending HTML with custom tags and attributes. (ng-whatever, for example.) Having no support for providing semantics for such things is pretty ridiculous.
- zozbot123 8y ago
  > Still requires to use valid URLs instead of GUIds. Not sure why you would want to do this, but AIUI you can use any URI for a namespace (not just URL), including a UUID via the `urn:uuid:c1a3e0cb-5872-4e5a-8dce-b8afc00772db` syntax.
  - titanix2 8y ago
    You can but most of the time, especially with Linked Data, an URL is required. And sometime even a dereferencable one. So you have this weird situation where you never really know if an URL is "semantic" (just a string actually) or can be accessed. Also having a dependency on the DNS system is a bad idea in my opinion. It's really clear when you read 2 years old semantic web paper and every link is broken. I agree with gambler that GUID + local names is a better solution, and I use that in my research.

deleted 8y ago

[deleted]

tannhaeuser 8y ago

To answer your question, you can use HTML+RDFa to annotate any element with semantic info, or simply use meta-links (in the HTML head) for per-page metadata. W3C's semantic web is a lost cause, though, as is XHTML. I don't know why the paper speaks about "the first 20 years", as there's been zero activity for years and I think the semweb charters have been closed years ago. If you're interested in document engineering based on real and practical standards, I'd suggest looking into ISO SGML (superset of XML and HTML) and maybe ISO Topic Maps (with Tolog/ISO Prolog as query language).

iseeyoubydesign 8y ago

I have your answer and you are not going to like it. No matter how good an idea is its not picked up and proliferated unless big money is behind it. You got this nice library , great api. But company x doesnt use it, company x uses their library with their tools. Company x is hiring. So we learn company x tools. Think of every popular and unpopular frontend lib and ask yourself why its popular. jQuery is the only thing that comes to mind without a huge player, it just established itself at the right time.

henryluo 8y ago

I've come up with a new notation Mark (http://marknotation.org/ http://marknotation.org/), to address some of issues faced with JSON and XML. It keeps the simplicity of JSON, and is able to support mixed content at the same time. At the moment, it leaves out namespace to the application. Your sample in Mark would look like: {html {head {concept tag:computer-game guid:"c1a3e0cb-5872-4e5a-8dce-b8afc00772db"} {concept attribute:year-published guid:"ba073188-8bd6-47a7-9065-eb55c4a8b908"} } {body {computer-game year-published:1993 "Doom"} } }

gambler 8y ago
Looks pretty good. Not sure how I feel about including JSON as type of embedded content, though. I've used something vaguely similar in the distant past, but it was strictly internal for my hobby projects and mostly resembled lisp with square brackets. It was way more primitive, but the parser (lexer, really) fit into two blocks of code. All the fancy stuff was done within DOM.