[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Enigma-devel] Re: Comments on the level xml schema

From: Tacvek
Subject: [Enigma-devel] Re: Comments on the level xml schema
Date: Sun, 9 Apr 2006 16:19:43 -0400

----- Original Message ----- From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Sunday, April 09, 2006 6:51 AM
Subject: Re: Comments on the level xml schema


Tacvek wrote:
You define "xml:lang" as "en" on the <xs:schema>. This is good, and is a practice reccomended by the Schema documentaion in the case that all <xs:documentation> tags are in the same language. When <xs:documentation> is available in multiple languages
then it is reccomended to drop that attribute from <xs:schema>.

There will be no <xs:documentation> in multiple languages. I try to make very limited use of <xs:documentation> as it makes schemas quite unreadable.

You will find only technical infos in my <xs:documentation>. The "user" documentation you will find in the Enigma reference manual. This documentation is very detailed on all semantical aspects. I keep the reference manual up to date with the schema. Note that not all features may yet be supported by the trunk version - read the commit messages about progress.

I have, sometime after I sent this message I read all of the SVN messages, back to when I stopped paying attention to Enigma. I'm fairly clear on the current status of Enigma. One slight criticism is that much of the development is not discussed on this list, but it really
is not a problem. Occasional status messages could help.

As for including only techinical notices in the schema, That is a valid design choice. I would personally include full documention in the schema, and use that to generate documentation. As you are maintaing seperate documentation there is no need for that.

It is more a stylistic choice than anything else.

It may be desireable to include optional attributes in the basic form
<xs:attribute ref="xml:space" default="preserve"/>
Changing "preserve" to whatever would fit that element.
On the other hand that syntax would allow a level to change
the "xml:space" attribute. If that is not desireable then
"fixed" should be used rather than default. Of course
there is no need whatsoever to add that tag, but it is reasonable.

I hope the level authors can live with the current whitespace default handling. I would like to keep the schema as simple as possible - for readability and maintance purposes.

Indeed. The idea is completely optional. The main use would be to assist generic automated processing tools in deciding where whitespace is safe to alter, and where it is not.

[Comments on the format itself (at least as defined by the schema)]

"Titel" is German. As all the other tag/attribute names are in English (AFAICT), perhaps "title" should be used.

A typo - thanks, no one did spot this one yet!

That one jumped out at me.

Again I want to remember the author to supply an easy mode - technically an optional attribute with default value would be equivalent.

Yeah. The reminder to build an an easy mode is a reasonable reason to leave it as-is.

Rather than use an attribute in the Enigma namespace, it is recomended that "xml:lang" be used.
See: http://www.w3.org/International/questions/qa-when-xmllang
The appropriate tag is:
  <xs:attribute ref="xml:lang" use="required"/>
The level schema would require an import statement so that a parser could find the schema fragment that
defines xml:lang. The statement required is:
 <import namespace="http://www.w3.org/XML/1998/namespace";

I started with xml:lang, but did run into serious technical trouble. As far as I remember it was related to Xalan with the stylesheets that extract the translations and Xerces C++, too. Instead of spending my time to fix these problems I advanced with Enigma.

Reasonable. A bit of a stylistic concern, and not really an issue.

BTW I do want to keep Enigma capable of running standalone. Thus I do not want to import a schema from the internet and extending the resolver to take a local copy seems not to be worthwhile the benefits.

Too true. One of the problems with the XML Schema concept is that if
there is no available schema for a namespace then complete Schema-based validation
becomes impossible. The other problem is how to resolve a namespace into
a schema. The only useful system would be to have a local schema catalog
that parsers search to find definitions of namespaces. That is pretty much the
same system that DTDs used. [OT: As DTDs are a form a schema, it would
be desirable to be able to define XML entities in an XSD, so that DTDs could
be fully abandoned.]

[Comment on the current xml level examples]
It seems that it may be wise to use the default namespace feature in the level files to avoid excess prefixes.

As I want to separate Enigma's schema elements from those private once added by a level editor we have to live with the prefixes.

That is reasonable. On the other hand, editors should be using a unique
prefix for themselves anyway, as use of the default prefix is valid, and annother editor may output levels that use the default namespace feature for the level
files. The use of two editors may be more common than one might suspect.
A user may find that one editor is good for quickly laying out a level, but
annother editor may be better for the fine tuning of a level.

P.S. You did receive my makefile fragment for generating lua-*.* from *-lua.pkg right?

Your makefile rules may need configure.ac modifications, as with a fresh checkout from the repository the modification dates of *.cc and *.pkg are undetermined, but we cannot rebuild *.cc from *.pkg until we have tolua++. And tolua++ does not exists on process of configure.ac. That was the reason I first asked for a makefile target and not rules (and I guess the reason why Daniel did comment out the old rules). Just need some time to find a proper solution.

Hmm... Quite a long time ago everything worked perfectly. Tolua was used
when needed, and tolua was available because the tools directory was built before the main directory. Note that the current configure script appeared to set $TOLUA to 'tools/tolua' automatically for me. However, I've never been very clear on the way
version control systems handle modification dates. It may be that the old
method worked fine for CVS and/or TLA, but does not work with SVN.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]