Refine explanation of BEAR.Sunday's ROA vs MVC architecture

This revision enhances the explanation of how the BEAR.Sunday's ROA (Resource-Oriented Architecture) approach differs from the traditional MVC (Model-View-Controller) architecture in both English and Japanese versions. This improved clarification includes descriptions of component interactions, differences between controllers and models, constraints, and the usage of semantic methods or operations.

manuals/1.0/en/15.tech.md

@@ -78,15 +78,17 @@ By using BEAR.Sunday's ROA, scalable and loosely coupled applications that align
 ### Differences from MVC
 
 BEAR.Sunday's ROA takes a different approach than the traditional MVC architecture.
+BEAR.Sunday's ROA takes a different approach compared to the traditional MVC architecture. MVC structures an application with three components: Model, View, and Controller. In practice, however, the Controller freely manipulates the Model and View at runtime, literally controlling everything.
 
-* MVC controllers tend to have multiple responsibilities, but BEAR.Sunday resources follow the Single Responsibility Principle (SRP) with DI and AOP, distributing responsibilities.
-* MVC controllers perform various operations, but BEAR.Sunday resources have semantic methods (semantically clear methods), making operations explicit.
-* BEAR.Sunday uses embedded resources to declaratively indicate content inclusion relationships. This not only makes the relationships between resources explicit but also allows for dependency resolution for cache invalidation.
-* BEAR.Sunday resources themselves have the responsibility of representation, increasing self-sufficiency.
-* BEAR.Sunday resources provide possible operations (affordances) by declaring relations. Clients can dynamically operate on resources using this as a clue. It is self-descriptive.
-  HAL (Hypertext Application Language) is adopted for links, standardizing links between resources.
-* Unlike MVC models, they can be directly called from diverse clients including the console.
-* There is no need to build HTML and API sites separately; HTML and API sites can be built simultaneously using the same resources.
+In contrast, with BEAR.Sunday, the View is injected into the Resource object, and the Resource is unaware of the View, just as the View is unaware of the Resource. The Resource object does not manipulate the injected View and does not even know what kind of View has been injected. Only when the Resource object is evaluated as a string does the injected View render the Resource's state into a string representation. In this way, the Resource and View are loosely coupled, and their responsibilities are clearly separated.
+
+Furthermore, unlike the unconstrained relationship between Controller and Model, Resources have constraints on including other Resources, which can be done declaratively. The Resource also depends on different Resources, forming a tree structure similar to DI dependencies. Other differences include:
+
+* While MVC Controllers have no constraints and are free to operate, BEAR.Sunday Resources have semantic methods (semantically clear methods), making operations explicit.
+* BEAR.Sunday Resources provide possible operations (affordances) by declaring relationships. Clients can dynamically manipulate Resources using this as a clue. It is self-descriptive.
+  HAL (Hypertext Application Language) is adopted for links, standardizing the links between Resources.
+* Unlike MVC Models, Resources can be directly called from various clients, including the console.
+* There is no need to build HTML sites and API sites separately; the same Resources can be used to build both HTML sites and API sites simultaneously.
 
 ## Event-Driven Content Strategy Based on ROA by Integration with Modern CDN
 

manuals/1.0/ja/15.tech.md

@@ -78,14 +78,14 @@ BEAR.SundayのROAを用いることで、Webの設計原則に沿ったスケー
 
 ### MVCとの相違点
 
-BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。
-
-* MVCのコントローラーは複数の責任を持ちがちですが、BEAR.SundayのリソースはDIとAOPで単一責任の原則（SRP）に従い、責任が分散されています。
-* MVCのコントローラーは様々な操作を行いますが、BEAR.Sundayのリソースはセマンティックなメソッド（意味的に明確なメソッド）を持ち、操作が明確になります。
-* BEAR.Sundayでは埋め込みリソースを使い、コンテンツの内包関係が宣言的に示されます。これによりリソース間の関係性が明示的になるだけでなく、キャッシュ無効化のための依存解決も行えます。
-* BEAR.Sundayはリソース自身が表現の責任を持ち、自己完結性が高まります。
-* BEAR.Sundayのリソースはリレーションを宣言することで、可能な操作（アフォーダンス）を提供します。クライアントはこれを手がかりにリソースを動的に操作できます。自己記述的です。
-  リンクにはHAL（Hypertext Application Language）を採用し、リソース間のリンクを標準化します。
+BEAR.SundayのROAは、従来のMVCアーキテクチャとは異なるアプローチをとっています。MVCはモデル、ビュー、コントローラーの3つのコンポーネントによってアプリケーションを構成しますが、実際はコントローラーがモデルやビューを自由にランタイムで操作し、あくまでコントローラーが文字通り全てをコントロールしています。
+
+これに対して、BEAR.Sundayではリソースオブジェクトにビューがインジェクトされ、リソースはビューに対して無知であると同時に、ビューもまたリソースに対して無知です。リソースオブジェクトはインジェクトされたビューに対して操作を行いませんし、そもそもどのようなビューがインジェクトされたのかも知りません。リソースオブジェクトが文字列評価された時に初めて、インジェクトされたビューがリソースの状態を文字列表現にレンダリングします。このように、リソースとビューは疎結合であり、それぞれの責務が明確に分離されています。
+
+また、コントローラーとモデルの関係に制約がないのと対照的に、リソースは他のリソースを含むことに制約があり、宣言的に行うことができます。そのリソースはまた違うリソースに依存し、まるでDIの依存性のようにツリー構造を形成します。その他以下のような違いがあります。
+
+* MVCのコントローラーの操作に制約はなく自由ですが、BEAR.Sundayのリソースはセマンティックなメソッド（意味的に明確なメソッド）を持ち、操作が明確になります。
+* BEAR.Sundayのリソースはリレーションを宣言することで、可能な操作（アフォーダンス）を提供します。クライアントはこれを手がかりにリソースを動的に操作できます。自己記述的です。 リンクにはHAL（Hypertext Application Language）を採用し、リソース間のリンクを標準化します。
 * MVCのモデルと違って、コンソールを含む多様なクライアントから直接コールすることができます。
 * HTMLサイトとAPIサイトを別々に構築する必要がなく、同じリソースを使ってHTMLサイトとAPIサイトを同時に構築できます。