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

[Tacvek]

----- 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


> Hi,
>
> 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";
> >               schemaLocation="http://www.w3.org/2001/xml.xsd"/>
>
> 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.