> > Normally, namespaces should also work with DTD, ensuring proper
> > validation (or did I miss something ?)
>
> As far as I can tell, the one-and-only DTD that you declare at the top of
> your original source document is the only one that is used for the entire
> thing -- and this DTD has to be the union of all the valid elements and
> attributes. And I don't know how to create a DTD that "imports"
> struts-config_1_1.dtd and adds to it :-(.
>
I believe you're correct. There is no facility in DTD's for allowing them
to be altered in this way. Especially since it is likely that some of the
changes people may want to do could involve adding "attibutes" to existing
elements or new sub-elements. For example:
<action path="/html-link"
type
="org.apache.struts.webapp.exercise.HtmlSettersAction"
name="testbean"
scope="session"
validate="false"
e.g. 1 --> myAttribute="myValue">
<forward name="input" path="/html-link.jsp"/>
e.g. 2 --><MyElement myAttribute1="myValue1" />
</action>
Namespaces wouldn't handle this on their own, you'd have to modify the dtd
itself to get things to validate.
It may be possible to generate DTD's at build time from an XML file -
something like a Torque for DTD's. There could be default XML file that is
used to generate the default DTD. This way, the users could modify the
struts-config.xml anyway they want and still have a valid DTD to validate
with.
> > In fact, I think of using namespaces in struts-config to allow
> > "inline" declaration of a Tiles definitions inside a <forward>.
Creating dtd's dynamically this way would allow Cedric (or others) to add
declarations directly inside existing elements. To accomplish what I belive
Cedric is saying would require the DTD itself to be modified - that is
adding Tiles elements directly inside <forward>'s.
> > Regarding some previous mails I think it is a similar requirement than
> > for the <transform> tag. So, we should certainly propose a common and
> > general solution for this kind of extension.
Here is a proposal:
1. Create an XML file and a process (perhaps XSLT-based) for creating the
dtd from it.
2. Create an Ant task that performs this translation so that modifications
to the dtd occur at build time.
3. Provide a standard XML document that will generate the standard dtd.
4. Allow users/contributors/et al to provide INCREMENTAL XML files that add
mods to the DTD. This way, it would be possible to build a DTD containing
multiple contributions without having to consolidate multiple mods into a
single XML file maunally.
So each contributor (or user) that wants to modify the DTD can create an
XML file with the DTD mods in it that are required for their entries to
validate. Then at build time, they are all read and the actual dtd is
built.
I know this seems complicated, but here are a couple of good reasons for
it:
- It allows multiple contributors to easily manages changes to the dtd
that their code needs.
- It allows for contributors and users to add elements/attributes to
existing elements in the config while allowing validation.
- It makes it possible to have users/contributors add elements without
requiring namespaces or XMLSchema. Once you add namespaces and XMLSchema to
the mix things will get much more difficult to understand for an average
user.
Kevin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
