Dopuszczam możliwość, że nie rozumiem idei HATEOAS, ale może porównanie do czegoś znajomego ułatwi zmianę spojrzenia. Wydaje mi się jednak, że to "well known" to już dawno było w XML/XSD.
Tak, ale to dalej nie to samo. Zdanie Zamek jest czarny. jest poprawne składniowo, tak samo dokument <entry><what>Zamek</what><colour>Black</black></entry>. Oba są poprawne (wg zadanej składni), ale w obu przypadkach nie mamy znaczenia słowa zamek. XSD jest zupełnie niezależne od HATEOAS, bo XSD opisuje składnię, a nie znaczenie poszczególnych elementów. Rozumiesz co mam na myśli?
Wydaje mi się, że wiem o co Ci chodzi, ale nie wiem czy w drugą stronę się jasno wyraziłem. Możliwe, że mówimy o tym samym z perspektywy różnych technologii. Możliwe też, że nadal nie wiem co masz na myśli :) Za pomocą XSD można opisać też znaczenie, nie tylko składnię, ale może to moje przeświadczenie?
Dla tego przykładu (zakładam, że podałeś wersję uproszczoną):
<entry><what>Zamek</what><colour>Black</black></entry>
pomijasz element jakim jest odwołanie do schemy, w ramach, której należałoby treść interpretować. Sama treść, bez odwołania do schematu, nie niesie informacji łatwej w przetwarzaniu dla maszyn, ale jak już dodamy schematy, to się zmienia.
(Przykłady pisane z palca, więc mogą mieć różne braki.)
<entry xmlns="http://moje.schematy/budynki/Zamki">
<what>Zamek</what><colour>Black</colour>
</entry>
<entry xmlns="http://moje.schematy/mechanizmy_bezpieczenstwa/Zamki">
<what>Zamek</what><colour>Black</colour>
</entry>
Możemy je również mixować i wyrażać sens typu: W czarnym zamku jest złoty zamek, co ludziom może stwarzać problemy, ale maszynom już nie.
<entry xmlns:b="http://moje.schematy/budynki/Zamki"
xmlns:l="http://moje.schematy/mechanizmy_bezpieczenstwa/Zamki">
<b:what>Zamek</b:what><b:colour>Black</b:colour>
<l:what>Zamek</l:what><l:colour>Gold</l:colour>
</entry>
Przykładowych schematów nie generuję, bo nie wnoszą jakieś istotnej wartości dla zilustrowania tego o co mi chodzi z tym nadawaniem znaczenia zawartości treści wyrażonej w dokumencie XML. Jednak tworząc schemat, starałbym się odwzorować biznesowe znaczenie i miał w schemacie typ Zamek, który ma elementy składowe (Wieza, Fosa, Brama etc. wraz z odpowiednimi atrybutami per typ, np. Fosa -> szerokosc, glebokosc ). W schemacie miałbym też kontrolę struktury (krotność, opcjonalność, kolejność etc.). Maszyna znając schemat może sobie spokojnie przetwarzać zgodnie ze schematem, który zna.
Jeśli:
- z HTMLa wytniemy
itemtype="http://schema.org/Event" ,
- z JSONa wytniemy
"@context": "http://schema.org", "@type": "Event", ,
to pewnie maszyny przestaną rozumieć co jest czym. Tak samo jak pominięcie odwołania do schematu w dokumencie XML.
Inaczej mówiąc cała idea HATEOAS jest taka, by komputer był w stanie z HTMLa i JSONa wyciągnąć te same dane i wiedzieć dokładnie co każde z nich oznacza.
W tym miejscu wypadałoby zadać pytanie, "Dlaczego maszyna, bez konceptu HATEOASa, nie była/jest w stanie z HTML i JSON wyciągnąć danych i rozumieć znaczenia, bez konceptu HATEOASa?" Może powstał w wyniku potrzeb pudrowania braków w architekturach RESTowych? Nie oceniam, że to crap, tylko głośno myślę by sprowokować reakacje :)
Dzięki za podjęcie tematu i wysiłek włożony w dyskusję.