Bueno, ahora no puede ser útil si aún no se ha inventado. Sin embargo, voy a tener una grieta en esto.
Las tecnologías web evolucionan. Esto es algo bueno, pero significa que las páginas se rompen cuando las tecnologías y estándares antiguos desaparecen y no se muestran correctamente cuando los estándares continuos (como HTML5) desarrollan conceptos que nunca se implementan lo suficiente como para que los navegadores implementen y prueben esos conceptos de manera uniforme.
El HTML se usa cada vez más para medios más complejos, como los libros, pero simplemente carece del tipo de poder necesario para escribir y la composición es inútil para las páginas web. HTML también está resultando extremadamente difícil para los conceptos semánticos.
- Tengo una invención destacada de gorro para el cabello ... me gustaría venderlo directamente a una empresa. ¿Qué compañía debo probar y cómo me comunico con ellos?
- ¿Las matemáticas son algo que inventamos para explicar el universo o algo que descubrimos sobre el universo?
- ¿Cómo podemos inventar la teletransportación?
- ¿Por qué no hay autos andantes? ¿Por qué nadie ha intentado inventar ninguno?
- ¿Qué cosas interesantes o útiles te gustaría ver inventar a alguien?
Por lo tanto, esperaría que se desarrollara un metaformato, donde el marcado se convierte directa y confiablemente a absolutamente cualquier lenguaje de marcado existente o combinación de lenguajes de marcado y puede convertirse fácilmente en cualquier estándar futuro, haciendo uso de nuevas características en ese estándar. Esto significa que el metaformato debe ser Turing-Complete, de lo contrario existirá un futuro lenguaje de marcado al que no se puede traducir.
Si desea un lenguaje que sea compatible con HTML 5, CSS 3, LaTeX 3, Java Swing, Flash, VRML, OWL 2, GDML, GML, UML y cualquier otra cosa que se le ocurra, tiene que ser un poco más sofisticado de lo que existe actualmente disponible en tierra de metalenguaje.
Pero querías una API, no un ML. La API necesaria para acceder programáticamente a toda esta funcionalidad no es tan mala como cabría esperar.
Un objeto, ya sea un libro, una página o cualquier cosa en él, etc., tiene estructura. Los objetos atómicos deben tener contenido, que puede estar en uno o más atributos. Todos los demás objetos deben tener relaciones con otros objetos (atómicos o compuestos) donde el tipo de relación se describe por la relación. Un razonador debe ser capaz de determinar cualquier otra información requerida de esta estructura.
El gráfico no debe describir cómo se hacen las cosas o cómo deberían verse las cosas. Todo eso debe ser derivado por el razonador y el compilador fuente-fuente. Solo se debe proporcionar la estructura abstracta de los documentos y la especificación abstracta de los conceptos gráficos.
Por lo tanto, la API debe tener algo en este sentido:
Nuevo (clase de objeto compuesto, plantilla abstracta)
Asociado (objeto, objeto)
Enlace (Asociación, Atributos de relación)
Nuevo (clase de objeto atómico, propiedades del objeto atómico)
Compilar (objeto)
No quieres atributos en objetos compuestos. Siempre deben estar en objetos que están vinculados. De esta manera, desacopla generalidades y detalles. De lo contrario, no podrá obtener esto completamente generalizado.
La estructura no es jerárquica, es un gráfico dirigido con arcos explícitos e implícitos entre los nodos. Los arcos implícitos significan que lo que quieres decir no siempre es lo que dices. Los gráficos crean flujos mucho más interesantes y, por lo tanto, pueden codificar conceptos programáticos, relaciones recursivas y otras ideas que son muy útiles si está tratando de describir el algoritmo sin implementarlo. Si se requiere una secuencia forzada, bastarán las clases atómicas que formulan una red de Petri coloreada. No necesita hablar de implementación.
No le importan las ineficiencias, esto no se utilizará para entregar contenido, sino para convertir información en bruto en tipos específicos de información.
La plantilla puede ocuparse de lo que significa el contenido, los flujos dicen cómo se relacionan las cosas entre sí, de modo que todo se ocupa de lo básico. Es suficiente para todo excepto contenido dinámico y E / S. Para esto, la API necesita extenderse:
Nuevo (tipo de objeto de origen, URI de origen)
Nuevo (tipo de objeto de datos, URI de datos)
Nuevo (tipo de especificación abstracta, especificación abstracta)
Nuevo (tipo de canal, canal)
Estos crearían objetos que podrían vincularse como antes. Ahora puede definir entradas específicas como conformes con gramáticas específicas, compiladas de acuerdo con un tipo de datos abstractos, validadas colectivamente y transformadas por Z, y luego publicadas en una base de datos. El compilador puede convertir eso en lo que quiera, no le importa, lo único que importa es que está garantizado para generar lo que quiso decir, independientemente de la tecnología del día.
¿Ineficiente? Sí. Muy. ¿Complejo? Definitivamente, pero no es peor que la horrible combinación de estándares modernos y es mantenible.
No hay referencia a HTTP, en parte porque es un estándar ineficiente y en parte porque las páginas web no deberían preocuparse por los protocolos de entrega más allá de decir cómo obtienen los datos. E incluso entonces, sería mejor usar un formato direccionable por contenido que un URI, pero no hay un estándar aceptado en todas las fuentes para eso en este momento.
