Ah, so the annotations in the schema go beyond what is needed for
validation and for documentation. I guess I had assumed otherwise.
But it does sound like there's nothing to prevent us from moving
annotations from schema comments into javadoc-style script comments,
except the hassle and expense of doing so. That is, I could imagine
doing everything you list below using script comments -- even type
decls in the interim -- but presumably we'd then have to start
parsing script comments in the script compiler to extract that
information.
jim
On Oct 30, 2006, at 1:40 PM, P T Withington wrote:
We'd need more annotation in script, since you can't (easily) tell
which class properties represent internal implementation and which
represent schema properties. We'd also have to get cracking with
allowing type declarations and optional arguments in script
(something the schema currently encodes). And, we'd have to come
up with a way of declaring which attributes can appear in the open
tag vs. only in the body (or eliminate that distinction).
In short, I think this is a nobel goal, but there is a huge gap
between schema and script.
OTOH, we already have a mechanism (as Henry describes) for deriving
schema from LZX, so perhaps an interim goal is to describe the
built-in classes in LZX for building the schema (even though their
implementation is in script). My analogy is a C function whose
body is asm();, we should have a way to write an LXZ class
interface with a body that is pure script.
On 2006-10-30, at 16:25 EST, Jim Grandy wrote:
Right, but my supposition is that there's enough information in
the LFC sources to create (most of) the in-core DOM tree using the
same mechanism. If <node> is in the base schema, then the schema
rules for <view> can be built by parsing the LFC. This would
eliminate a class of bugs and simplify the base schema enormously.
But I'm ready to believe I'm missing some fundamental gotcha that
prevents this from being feasible.
On Oct 30, 2006, at 1:20 PM, Henry Minsky wrote:
If I recall correctly, the way that the tag compiler works now,
when it sees a <class> tag, it
1) detemines the superclass name
2) looks in the schema DOM and finds the definition element
that represents the superclass
3) deep copies it
4) extends it with any new attributes that the new class declares
So the schema in-core DOM tree is dynamically extended with each
user class <class> tag
So to "bootstrap" the system, the schema has to be seeded with
some definition of each class that
you want to be able to extend in LZX.
'node' and 'view' are the most popular things to extend, but the
tag compiler can extend anything
that is declared in the base schema, since it just looks for the
superclass definition and clones it.
