Stefan Bodewig wrote:
On Tue, 24 May 2005, Jan Materne <[EMAIL PROTECTED]> wrote:
But I like the 3rd paragraph
I still do as well. I'm just not sure that XML Schema would be the
way to go.
no, I think we all under stand XSD that much better now :(
/** Returns all names of required attributes. */
public static String[] getRequiredAttributes();
Doesn't help with the "exactly one of these three attributes is
required" cases. Or even "either this or a nested foo element is
required".
Maybe you could ask a component for a bit of a schema (note I didnt say
XSD) that describes itself.
FWIW, in the smartfrog langage you just declare an (optional) schema
with a template. This is just an extensible/overridable hint; validation
checks that every type that is referred to can take what it is given.
Vector : a list of stuff
Compulsory: anything, but it must be supplied. That element can take a
string or a CD
CD: component description (another nested thing)
There are optional types too (e.g. OptionalBoolean), and you can derive
your own by extension.
Libraries extends Compound {
librariesSchema extends Schema {
repositories extends Vector;
//cache dir; is created if needed
cacheDir extends Compulsory;
/**
* Component implementing local cache policy
*/
localCachePolicy extends CD;
/**
* Component implementing local cache policy
*/
remoteCachePolicy extends CD;
}
The XML equivalent language, being done under the auspices of various
"standards" bodies, uses XSD for its type model, which is a lot more
painful to work with, either to write or to code support for. Which is
why we've retained something else from the SmartFrog language, the
typeless placeholder flag:
JVM extends Executable {
classname TBD;
execuable "java";
}
Here when I describe my type I say "this has to be filled in with
something". All full validation is done procedurally, when the various
things are instantiated. Unlike Ant (where the runtime calls the
setters), the SmartFrog runtime lets components get stuff off the graph.
Most interestingly, it lets you dynamically update the graph. So when
the libraries component is instantiated, it adds a new attribute, the
vector of paths to downloaded JARs, the JVM then links to that attribute
with a lazy marker (LAZY /cdl:lazy="true" depending on language) to tell
the framework that this binding is runtime and not parse time.
Being able to add stuff to the graph is very powerful. Some components
rewrite themselves as they go, so functions, for example, evaluate and
then replace their component description (i.e. a Parent Node) with a
string instead. Course, it makes defect tracking kind of fun too.
I think RelaxNG makes it easier to say "attribute a or b, but not both".
}
How the IDEs solve that at the moment?
Do they?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
