You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by ni...@apache.org on 2004/04/22 13:13:29 UTC
svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation src/documentation
Author: nicolaken
Date: Thu Apr 22 04:13:28 2004
New Revision: 10172
Modified:
xml/forrest/branches/copyless/build.xml
xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
xml/forrest/branches/copyless/src/documentation/skinconf.xml
Log:
Remove DTD from skinconf and make it validate as simple XML.
Modified: xml/forrest/branches/copyless/build.xml
==============================================================================
--- xml/forrest/branches/copyless/build.xml (original)
+++ xml/forrest/branches/copyless/build.xml Thu Apr 22 04:13:28 2004
@@ -212,6 +212,7 @@
<!-- skinconf.xml -->
<echo message="validating **/skinconf.xml ..."/>
<xmlvalidate failonerror="true" lenient="no" warn="yes">
+ <attribute name="http://apache.org/xml/features/validation/dynamic" value="true"/>
<xmlcatalog >
<dtd publicId="-//APACHE//DTD Skin Configuration V0.6//EN"
location="src/core/context/resources/schema/dtd/skinconfig-v06.dtd"/>
Modified: xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
==============================================================================
--- xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml (original)
+++ xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml Thu Apr 22 04:13:28 2004
@@ -19,11 +19,6 @@
Skin configuration file. This file contains details of your project, which will
be used to configure the chosen Forrest skin.
-->
-
- <!DOCTYPE skinconfig PUBLIC
- "-//APACHE//DTD Skin Configuration V0.6//EN"
- "skinconfig-v06.dtd">
-
<skinconfig>
<!-- Do we want to disable the Lucene search box? -->
<disable-lucene>true</disable-lucene>
Modified: xml/forrest/branches/copyless/src/documentation/skinconf.xml
==============================================================================
--- xml/forrest/branches/copyless/src/documentation/skinconf.xml (original)
+++ xml/forrest/branches/copyless/src/documentation/skinconf.xml Thu Apr 22 04:13:28 2004
@@ -20,59 +20,6 @@
be used to configure the chosen Forrest skin.
-->
-<!DOCTYPE skinconfig [
-
- <!ENTITY % links.att 'name CDATA #REQUIRED'>
- <!ENTITY % link.att 'name CDATA #REQUIRED href CDATA #REQUIRED'>
- <!ELEMENT skinconfig (disable-lucene?, disable-search?, disable-print-link?, disable-pdf-link?,
- disable-xml-link?, disable-compliance-links?, obfuscate-mail-links?, searchsite-domain?, searchsite-name?,
- project-name, project-description?, project-url, project-logo, group-name?, group-description?, group-url?, group-logo?,
- host-url?, host-logo?, favicon-url?, year?, vendor?, trail?, toc?, credits?)*>
- <!ELEMENT credits (credit*)>
- <!ELEMENT credit (name, url, image?, width?, height?)>
- <!-- id uniquely identifies the tool, and role indicates its function -->
- <!ATTLIST credit id CDATA #IMPLIED
- role CDATA #IMPLIED>
- <!ELEMENT disable-lucene (#PCDATA)>
- <!ELEMENT disable-search (#PCDATA)>
- <!ELEMENT disable-print-link (#PCDATA)>
- <!ELEMENT disable-pdf-link (#PCDATA)>
- <!ELEMENT disable-xml-link (#PCDATA)>
- <!ELEMENT disable-compliance-links (#PCDATA)>
- <!ELEMENT obfuscate-mail-links (#PCDATA)>
- <!ELEMENT searchsite-domain (#PCDATA)>
- <!ELEMENT searchsite-name (#PCDATA)>
- <!ELEMENT project-name (#PCDATA)>
- <!ELEMENT project-description (#PCDATA)>
- <!ELEMENT project-url (#PCDATA)>
- <!ELEMENT project-logo (#PCDATA)>
- <!ELEMENT group-name (#PCDATA)>
- <!ELEMENT group-description (#PCDATA)>
- <!ELEMENT group-url (#PCDATA)>
- <!ELEMENT group-logo (#PCDATA)>
- <!ELEMENT host-url (#PCDATA)>
- <!ELEMENT host-logo (#PCDATA)>
- <!ELEMENT favicon-url (#PCDATA)>
- <!ELEMENT year (#PCDATA)>
- <!ELEMENT vendor (#PCDATA)>
- <!ELEMENT trail (link1, link2, link3)>
- <!ELEMENT link1 EMPTY>
- <!-- Seems we can't use param entity refs until this is DTDified -->
- <!ATTLIST link1 name CDATA #REQUIRED href CDATA #IMPLIED>
- <!ELEMENT link2 EMPTY>
- <!ATTLIST link2 name CDATA #REQUIRED href CDATA #IMPLIED>
- <!ELEMENT link3 EMPTY>
- <!ATTLIST link3 name CDATA #REQUIRED href CDATA #IMPLIED>
- <!ELEMENT name (#PCDATA)>
- <!ELEMENT url (#PCDATA)>
- <!ELEMENT image (#PCDATA)>
- <!ELEMENT width (#PCDATA)>
- <!ELEMENT height (#PCDATA)>
- <!ELEMENT toc EMPTY>
- <!ATTLIST toc max-depth CDATA #IMPLIED min-sections CDATA #IMPLIED
- location CDATA #IMPLIED>
- ]>
-
<skinconfig>
<!-- Do we want to disable the Lucene search box? -->
<disable-lucene>true</disable-lucene>
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation
src/documentation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema escribió:
> nicolaken@apache.org wrote:
>
>> Author: nicolaken
>> Date: Thu Apr 22 04:13:28 2004
>> New Revision: 10172
>>
>> Modified:
>> xml/forrest/branches/copyless/build.xml
>>
>> xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
>>
>> xml/forrest/branches/copyless/src/documentation/skinconf.xml
>> Log:
>> Remove DTD from skinconf and make it validate as simple XML.
>>
>
> Is this necessary? I thought cheche got it working well.
>
I did not read any of the messages from the copyless branch, so I was
not aware of this change.
I guess that until someone does not want to put it on the main trunk, it
should not been very important.
I am aware that there were some problems but I have just fixed.
Cheers,
Cheche
RE: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation src/documentation
Posted by "Brian S. Hayes" <br...@comcast.net>.
> In any case it's ridiculous that a user has to add values that go in
> skinconf to a stylesheet just because we want to validate a file without
> aded value.
IMHO, there's two types of users: the skin builders and the skin end-users.
As a skin builder, I'm willing to make necessary changes to have validation
so my skin end-users don't mess up.
However, I'm new to Forrest and may not understand the situation completely.
Best Regards,
Brian
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation
src/documentation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola,
>
> Nicola Ken Barozzi escribió:
>
>> The fact is that somehow I was still getting errors in the logs about
>> a missing DTD, so I got irritated and took them away. Ok, so this is
>> not a technical reason, but the more I think of it, the more it seems
>> to make sense. Do property files have a DTD? Do they need one?
>
> I think that you should always validate the input that comes from the user.
Too generic. We don't validate input from forrest.properties and still
don't have problems. As long as Forrest does not fail, it's not
necessary to validate on the tag types.
>> For example, let's say that somebody makes a skin that needs some
>> extra customization values... where do they put them? Without a DTD,
>> they can easily add them to the skinconf file.
>
> Even If I think that this is not our user requirement you can still
> doing that with your skinconf.xsl stuff.
>
> A user that need some extra values can added on a skinconf.xsl. If you
> check the results with http://localhost:8888/skinconf.xml you will see
> all the values.
I know, I wrote it.
In any case it's ridiculous that a user has to add values that go in
skinconf to a stylesheet just because we want to validate a file without
aded value.
>> What are the reasons we should keep the DTD, given the above point and
>> the problems we have been having till now (not no mention having to
>> make users update the DTD at every change)?
>
> because it allow to validate offline and to be used with old xml editors.
No validation works with any xml editor, even ones that don't use
*resolvers*. Remember in fact not many validate the files because the
"old" xml editors don't have a resolver.
It seems to be clear now that a simple DTD like the one I proposed
included in the xml is the best solution.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation
src/documentation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
Nicola Ken Barozzi escribió:
>
> The fact is that somehow I was still getting errors in the logs about a
> missing DTD, so I got irritated and took them away. Ok, so this is not a
> technical reason, but the more I think of it, the more it seems to make
> sense. Do property files have a DTD? Do they need one?
I think that you should always validate the input that comes from the user.
>
> For example, let's say that somebody makes a skin that needs some extra
> customization values... where do they put them? Without a DTD, they can
> easily add them to the skinconf file.
Even If I think that this is not our user requirement you can still
doing that with your skinconf.xsl stuff.
A user that need some extra values can added on a skinconf.xsl. If you
check the results with http://localhost:8888/skinconf.xml you will see
all the values.
>
> What are the reasons we should keep the DTD, given the above point and
> the problems we have been having till now (not no mention having to make
> users update the DTD at every change)?
>
because it allow to validate offline and to be used with old xml editors.
Cheers,
Cheche
Re: skinconf versioning (Was: svn commit: rev 10172)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
...
>>* any update to the skinconf that changes feature names will be included
>>in the general skinconf pipeline xsl
...
> Not sure what you mean by that last bit.
@see resources.xmap
There is a pipeline that transforms skinconf.xml with a number of
stylesheets before giving it to internal processing. If we change some
tags, we just need to add in the first xslt the right transformation,
and internally it will work as if nothing has happened. On my branch
even the skinconf input module (conf:) uses an internal pipeline.
>>>* Release Forrest more often.
>>
>>+1
>
> :-) we do need to try harder.
We did too many wide and all-encompassing changes to the trunk.
I believe that if we start using branches for them, we will be able to
do timed releases, ie one per month, as all things that have not yet
been resolved stay in the branches.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: skinconf versioning (Was: svn commit: rev 10172)
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
>
> This is correct as long as we assume that Forrest breaks on invalid
> config tags. All my reasoning instead is based on the assumption that
> any config file, even only one with <skinconf/> should work. In this way
> it won't be Forrest busting, but just a feature not appearing.
Ah, this is a good approach.
> David Crossley wrote:
> > Nicola Ken Barozzi wrote:
> >>For example, let's say that somebody makes a skin that needs some extra
> >>customization values... where do they put them? Without a DTD, they can
> >>easily add them to the skinconf file.
> >
> > The skinconf-*.rng could me more lenient, allowing them to
> > add extra optional stuff to their own skinconf.xml file.
>
> But then it won't really catch errors to remove the above problem.
By "lenient" i meant that there would be certain required stuff
and anything else would be optional in the RNG grammar (using
zeroOrMore AnyElement).
> Or maybe the current tag-specifies-a-function format is not the solution.
>
> Maybe something like:
>
> <skinconfig>
> <feature name="logo">
> <property name="name">Forrest"</property>
> <property name="url">http://xml.apache.org/forrest/</property>
> <property name="logo">images/project-logo.gif</property>
> </feature>
>
> <feature name="lucene" value="false"/>
>
> <feature name="search" value="true">
> <property name="domain">xml.apache.org</property>
> <property name="name">Apache XML</property>
> </feature>
> ...
> <feature name="obfuscate-mail-links" value="true"/>
> ...
> <!-- -->
> <feature name="credits" value="true"/>
> <element>
> <property name="name">Built with Cocoon</property
> <property name="url">http://xml.apache.org/cocoon/</property >
> <property name="image">images/built-with-cocoon.gif</property >
> <property name="width">88</property >
> <property name="height">31</property >
> </element>
> <element>
> <property name="name">...</property
> <property name="url">...</property >
> <property name="image">...</property >
> <property name="width">...</property >
> <property name="height">...</property >
> </element>
> ...
> </feature>
> </skinconfig>
>
> In this way we get lax and extensible elements but reasonable editing.
This is great. Keeps it simple and we can go back to an internal DTD.
> > I think that it is very important to have well-defined structure
> > for this file and to validate it before proceeding with the build.
> > If we don't control it, then i think we would descend into chaos.
>
> I don't agree, as we can't say that forrest.properties has gotten intop
> caos.
Gee, it can get very frightening in there.
<snip validation and constraints of old complex skinconf/>
> All of this seems really too complex.
>
> Let's say instead:
>
> * Forrest should work also without any skinconf element
>
> * there is a simple DTD used as a structure
>
> * features are listed in a doc file that is generated from the comments
> put in the fresh-site skinconf.xml
>
> * any update to the skinconf that changes feature names will be included
> in the general skinconf pipeline xsl
>
> WDYT?
+1 ... this is feeling a lot better.
Not sure what you mean by that last bit.
> > * Release Forrest more often.
>
> +1
:-) we do need to try harder.
--David
Re: skinconf versioning (Was: svn commit: rev 10172)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>The fact is that somehow I was still getting errors in the logs
>>about a missing DTD, so I got irritated and took them away.
>>Ok, so this is not a technical reason,
>
> Can't you just ignore the "error" until we get time to fix it. :-)
It seems that I can't get the SVG logos to render with it, don't ask me
why, I didn't investigate ;-)
>>...but the more I think of it, the more it seems to make
>>sense. Do property files have a DTD? Do they need one?
>
> Well i think that they do. I have never been able to understand
> how haphazard configuration files can ever support compatibility
> between versions.
>
> User: Hey, my so-and-so is busted!
> Support: Er, what version of the skinconf file do you have?
> User: Shrug, dunno.
> Support: You need to add the <so-and-so> tag.
> User: What is that, how do i use it?
> Support: Oh my god, not again.
This is correct as long as we assume that Forrest breaks on invalid
config tags. All my reasoning instead is based on the assumption that
any config file, even only one with <skinconf/> should work. In this way
it won't be Forrest busting, but just a feature not appearing.
>>For example, let's say that somebody makes a skin that needs some extra
>>customization values... where do they put them? Without a DTD, they can
>>easily add them to the skinconf file.
>
> The skinconf-*.rng could me more lenient, allowing them to
> add extra optional stuff to their own skinconf.xml file.
But then it won't really catch errors to remove the above problem.
<skinconf>
...
<searchseite-domain>my.org</searchseite-domain>
...
</skinconf>
The above will validate, as being lenient? It still creates problems.
Wouldn't it be easier to just do simple xml well-formedness?
>>What are the reasons we should keep the DTD, given the above point and
>>the problems we have been having till now (not no mention having to make
>>users update the DTD at every change)?
>
> One reason that i have heard, is that having a DTD declared
> for the skinconf.xml file enables people to use their favourite
> XML editor.
>
> I think that we are getting into this bind because we do not
> release Forrest often enough. The contracts with users via
> releases are too lax.
Or maybe the current tag-specifies-a-function format is not the solution.
Maybe something like:
<skinconfig>
<feature name="logo">
<property name="name">Forrest"</property>
<property name="url">http://xml.apache.org/forrest/</property>
<property name="logo">images/project-logo.gif</property>
</feature>
<feature name="lucene" value="false"/>
<feature name="search" value="true">
<property name="domain">xml.apache.org</property>
<property name="name">Apache XML</property>
</feature>
...
<feature name="obfuscate-mail-links" value="true"/>
...
<!-- -->
<feature name="credits" value="true"/>
<element>
<property name="name">Built with Cocoon</property
<property name="url">http://xml.apache.org/cocoon/</property >
<property name="image">images/built-with-cocoon.gif</property >
<property name="width">88</property >
<property name="height">31</property >
</element>
<element>
<property name="name">...</property
<property name="url">...</property >
<property name="image">...</property >
<property name="width">...</property >
<property name="height">...</property >
</element>
...
</feature>
</skinconfig>
In this way we get lax and extensible elements but reasonable editing.
> Dave Brondsema wrote:
>
>>The only users that have to update their DTDs frequently are people keeping up
>>with SVN. And in that case the DTD will make sure they keep up to date with any
>>changes.
>
> As users, we all need to keep our skinconf.xml files up-to-date
> anyway, so with or without a DTD, user-level changes need to be made.
Currently there is an auto-update for skinconf directly in the pipeline...
>>I'm ok without a DTD so long as we replace it with a (web) document that lists
>>and explains each element & attribute. It should be up-to-date all the time for
>>both the latest release and current SVN.
>>
>>And a [headsup] email to forrest-dev for any change to the skinconf that isn't
>>backwards compatable.
>
> It will be impossible to manually document the many different
> versions of the evolving skinconf structure.
>
> If we had a series of well-defined schema, then we have tools
> to automatically generate web-page documentation from them.
>
> I think that it is very important to have well-defined structure
> for this file and to validate it before proceeding with the build.
> If we don't control it, then i think we would descend into chaos.
I don't agree, as we can't say that forrest.properties has gotten intop
caos.
> Would this procedure be okay ...
>
> * Use a versioned namespace in the skinconf.xml
>
> * Do not declare a DTD in the skinconf.xml
>
> * Define a RELAX NG grammar with separate filename for
> each substantial change.
>
> * Document each change in status.xml
>
> * Release Forrest more often.
>
> * Generate a DTD from each RNG. Generate html doco too.
>
> * Users can insert a DTD declaration into their skinconf.xml
> if they want to (or configure their xml editor in some other way).
>
> * The Forrest build system strips any DTD declaration from the
> file before using it, so that the parser does not trip up on it.
> Is this really needed?
>
> * The Forrest build system uses the relaxng/schematron to
> validate the skinconf.xml - Jing can evidently respond to the
> namespace to apply the correct schema.
>
> * Add some build targets to automate skinconf upgrade.
All of this seems really too complex.
Let's say instead:
* Forrest should work also without any skinconf element
* there is a simple DTD used as a structure
* features are listed in a doc file that is generated from the comments
put in the fresh-site skinconf.xml
* any update to the skinconf that changes feature names will be included
in the general skinconf pipeline xsl
WDYT?
> * Release Forrest more often.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
skinconf versioning (Was: svn commit: rev 10172)
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> The fact is that somehow I was still getting errors in the logs
> about a missing DTD, so I got irritated and took them away.
> Ok, so this is not a technical reason,
Can't you just ignore the "error" until we get time to fix it. :-)
> ...but the more I think of it, the more it seems to make
> sense. Do property files have a DTD? Do they need one?
Well i think that they do. I have never been able to understand
how haphazard configuration files can ever support compatibility
between versions.
User: Hey, my so-and-so is busted!
Support: Er, what version of the skinconf file do you have?
User: Shrug, dunno.
Support: You need to add the <so-and-so> tag.
User: What is that, how do i use it?
Support: Oh my god, not again.
> For example, let's say that somebody makes a skin that needs some extra
> customization values... where do they put them? Without a DTD, they can
> easily add them to the skinconf file.
The skinconf-*.rng could me more lenient, allowing them to
add extra optional stuff to their own skinconf.xml file.
> What are the reasons we should keep the DTD, given the above point and
> the problems we have been having till now (not no mention having to make
> users update the DTD at every change)?
One reason that i have heard, is that having a DTD declared
for the skinconf.xml file enables people to use their favourite
XML editor.
I think that we are getting into this bind because we do not
release Forrest often enough. The contracts with users via
releases are too lax.
Dave Brondsema wrote:
> The only users that have to update their DTDs frequently are people keeping up
> with SVN. And in that case the DTD will make sure they keep up to date with any
> changes.
As users, we all need to keep our skinconf.xml files up-to-date
anyway, so with or without a DTD, user-level changes need to be made.
> I'm ok without a DTD so long as we replace it with a (web) document that lists
> and explains each element & attribute. It should be up-to-date all the time for
> both the latest release and current SVN.
>
> And a [headsup] email to forrest-dev for any change to the skinconf that isn't
> backwards compatable.
It will be impossible to manually document the many different
versions of the evolving skinconf structure.
If we had a series of well-defined schema, then we have tools
to automatically generate web-page documentation from them.
I think that it is very important to have well-defined structure
for this file and to validate it before proceeding with the build.
If we don't control it, then i think we would descend into chaos.
Would this procedure be okay ...
* Use a versioned namespace in the skinconf.xml
* Do not declare a DTD in the skinconf.xml
* Define a RELAX NG grammar with separate filename for
each substantial change.
* Document each change in status.xml
* Release Forrest more often.
* Generate a DTD from each RNG. Generate html doco too.
* Users can insert a DTD declaration into their skinconf.xml
if they want to (or configure their xml editor in some other way).
* The Forrest build system strips any DTD declaration from the
file before using it, so that the parser does not trip up on it.
Is this really needed?
* The Forrest build system uses the relaxng/schematron to
validate the skinconf.xml - Jing can evidently respond to the
namespace to apply the correct schema.
* Add some build targets to automate skinconf upgrade.
* Release Forrest more often.
--David
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation src/documentation
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Dave Brondsema wrote:
>
> > nicolaken@apache.org wrote:
> >
> >> Author: nicolaken
> >> Date: Thu Apr 22 04:13:28 2004
> >> New Revision: 10172
> >>
> >> Modified:
> >> xml/forrest/branches/copyless/build.xml
> >>
> >>
> xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
>
> >>
> >> xml/forrest/branches/copyless/src/documentation/skinconf.xml
> >> Log:
> >> Remove DTD from skinconf and make it validate as simple XML.
> >>
> >
> > Is this necessary? I thought cheche got it working well.
>
> That's a good question, and I hesitated to do it as well.
>
> The fact is that somehow I was still getting errors in the logs about a
> missing DTD, so I got irritated and took them away. Ok, so this is not a
> technical reason, but the more I think of it, the more it seems to make
> sense. Do property files have a DTD? Do they need one?
>
> For example, let's say that somebody makes a skin that needs some extra
> customization values... where do they put them? Without a DTD, they can
> easily add them to the skinconf file.
>
Very good point.
> What are the reasons we should keep the DTD, given the above point and
> the problems we have been having till now (not no mention having to make
> users update the DTD at every change)?
The only users that have to update their DTDs frequently are people keeping up
with SVN. And in that case the DTD will make sure they keep up to date with any
changes.
I'm ok without a DTD so long as we replace it with a (web) document that lists
and explains each element & attribute. It should be up-to-date all the time for
both the latest release and current SVN.
And a [headsup] email to forrest-dev for any change to the skinconf that isn't
backwards compatable.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
skinconf versioning (Was: svn commit: rev 10172)
Posted by David Crossley <cr...@apache.org>.
Brian S. Hayes wrote:
> Nicola Ken Barozzi wrote:
> > The fact is that somehow I was still getting errors in the logs about a
> > missing DTD, so I got irritated and took them away. Ok, so this is not a
> > technical reason, but the more I think of it, the more it seems to make
> > sense. Do property files have a DTD? Do they need one?
> >
> > For example, let's say that somebody makes a skin that needs some extra
> > customization values... where do they put them? Without a DTD, they can
> > easily add them to the skinconf file.
> >
> > What are the reasons we should keep the DTD, given the above point and
> > the problems we have been having till now (not no mention having to make
> > users update the DTD at every change)?
>
> One could argue that if you are savvy enough to being adding new values to
> the skinconf and making appropriate XSLT changes to the style sheets, then
> you can also make any DTD changes.
>
> Since I am new to Forrest, I am not confident that I understand who the
> target users are (in terms of what is expected of them). I think there are
> two users:
> 1. Savvy User: Knows XML, XSLT, CSS, XHTML, DTD, and XML Schema.
> 2. Basic Content Provider: Knows XML -- able to create content, edit
> skinconf.xml and forrest.properties, and to run forrest seed and forrest
> site.
Thanks for your input - all very valid points.
> A schema serves as the contract of what is the acceptable XML instance.
> With good in-line documentation, it can be a good reference. Thus, I argue
> for a schema of some sort (e.g. DTD, XML Schema, and/or Schematron).
>
> Has XML Schema been considered rather than using DTDs? The xs:any element
> would allow customization values to be added while also allowing for
> validation of the rest of the instance. I realize the schema choice (XML
> Schema, DTD, etc.) is a non-trivial consideration.
Not considered W3C XML Schema, but definitely considered Relax NG.
In fact we were also using RNG for this until a few weeks ago.
The trouble was that we also had an internal DTD subset in skinconf.xml
which has been a nightmare to maintain, both for developers and users.
> Another choice for validating skinconf instances would be Schematron.
Yes, and we can insert Schematron rules in the RELAX NG. We already
do that for the sitemap validation.
BTW Brian, your mailer has date of 23 March 2004 rather than
23 April 2004. Many people will miss your email because of
bad date sorting.
--David
RE: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation src/documentation
Posted by "Brian S. Hayes" <br...@comcast.net>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Nicola Ken Barozzi
> Sent: Thursday, April 22, 2004 3:52 PM
<snip/>
> The fact is that somehow I was still getting errors in the logs about a
> missing DTD, so I got irritated and took them away. Ok, so this is not a
> technical reason, but the more I think of it, the more it seems to make
> sense. Do property files have a DTD? Do they need one?
>
> For example, let's say that somebody makes a skin that needs some extra
> customization values... where do they put them? Without a DTD, they can
> easily add them to the skinconf file.
>
> What are the reasons we should keep the DTD, given the above point and
> the problems we have been having till now (not no mention having to make
> users update the DTD at every change)?
One could argue that if you are savvy enough to being adding new values to
the skinconf and making appropriate XSLT changes to the style sheets, then
you can also make any DTD changes.
Since I am new to Forrest, I am not confident that I understand who the
target users are (in terms of what is expected of them). I think there are
two users:
1. Savvy User: Knows XML, XSLT, CSS, XHTML, DTD, and XML Schema.
2. Basic Content Provider: Knows XML -- able to create content, edit
skinconf.xml and forrest.properties, and to run forrest seed and forrest
site.
A schema serves as the contract of what is the acceptable XML instance.
With good in-line documentation, it can be a good reference. Thus, I argue
for a schema of some sort (e.g. DTD, XML Schema, and/or Schematron).
Has XML Schema been considered rather than using DTDs? The xs:any element
would allow customization values to be added while also allowing for
validation of the rest of the instance. I realize the schema choice (XML
Schema, DTD, etc.) is a non-trivial consideration.
Another choice for validating skinconf instances would be Schematron.
Sincerely,
Brian
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation
src/documentation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> nicolaken@apache.org wrote:
>
>> Author: nicolaken
>> Date: Thu Apr 22 04:13:28 2004
>> New Revision: 10172
>>
>> Modified:
>> xml/forrest/branches/copyless/build.xml
>>
>> xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
>>
>> xml/forrest/branches/copyless/src/documentation/skinconf.xml
>> Log:
>> Remove DTD from skinconf and make it validate as simple XML.
>>
>
> Is this necessary? I thought cheche got it working well.
That's a good question, and I hesitated to do it as well.
The fact is that somehow I was still getting errors in the logs about a
missing DTD, so I got irritated and took them away. Ok, so this is not a
technical reason, but the more I think of it, the more it seems to make
sense. Do property files have a DTD? Do they need one?
For example, let's say that somebody makes a skin that needs some extra
customization values... where do they put them? Without a DTD, they can
easily add them to the skinconf file.
What are the reasons we should keep the DTD, given the above point and
the problems we have been having till now (not no mention having to make
users update the DTD at every change)?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: svn commit: rev 10172 - in xml/forrest/branches/copyless: . src/core/fresh-site/src/documentation
src/documentation
Posted by Dave Brondsema <da...@brondsema.net>.
nicolaken@apache.org wrote:
> Author: nicolaken
> Date: Thu Apr 22 04:13:28 2004
> New Revision: 10172
>
> Modified:
> xml/forrest/branches/copyless/build.xml
> xml/forrest/branches/copyless/src/core/fresh-site/src/documentation/skinconf.xml
> xml/forrest/branches/copyless/src/documentation/skinconf.xml
> Log:
> Remove DTD from skinconf and make it validate as simple XML.
>
Is this necessary? I thought cheche got it working well.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal