You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/04/26 10:29:07 UTC
[VOTE] New skinconf format
The latest happenings on skinconf have brought me to consider a format
for skinconf.xml.
Here is the proposal:
* Forrest should work also without any skinconf element: skinconf
elements are just hints, that a skin can decide not to follow
(as it happens already actually, just that the DTD makes people think
that Forrest will necessarily honor all hints)
* there is a simple DTD used as a structure (see below)
* 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
Here is a proposed skinconf:
<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.
The DTD will not change, so we can easily inline it in the XML, thus
making it trivial for validating editors to validate it (no catalogs to
set).
In this way we will have a simple skinconf DTD, that is both extensible
and formally validated.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
<my well-thought proposal>
>
> Honestly I don't like this approach, as it mixes things...
>
ok, fair enough
> What about this:
> - Remove DTD
Well, most of the trouble we have got in the last weeks, it has been
with the fact that we needed this DTD in place. Now I think that we need
to find out if we want this to be removed.
> - use only RelaxNG validation for it
>
> This should:
>
> - Keep it extensible by namespacing
> - Keep the stylesheets as are now
> - Keep validation (as RelaxNG IIRC runs on namespaces)
> - Make it loadable by XmlProperty
>
> What do others think, is this the right mix?
>
Re: [VOTE] New skinconf format
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
>
> What about this:
>
> - Add the forrest skinconf namespace
> - Remove DTD
I liked your suggestion of a simple internal
dtd with feature, element, property. That enabled
xml editors to easily do their stuff and provided
a basic level of validation.
> - use only RelaxNG validation for it
Yes, in that way thorough validation is a separate concern.
Surely we can then have various more sophisticated things
that check parameters against features, etc.
--David
Re: [VOTE] New skinconf format
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
...
> what about this:
>
> elements under <skinconfig> becomes standard ones.
>
> add <feature> elements under skincont like your prososal so it can be
> use for non-standard features.
>
> Adding this on the DTD should resolve it:
>
> <!ELEMENT feature (element*)>
> <!ATTLIST feature name CDATA #IMPLIED
> value CDATA #IMPLIED>
> <!ELEMENT element (property*)>
> <!ATTLIST element name CDATA #IMPLIED>
> <!ELEMENT property (#PCDATA)>
> <!ATTLIST property name CDATA #IMPLIED>
Honestly I don't like this approach, as it mixes things...
What about this:
- Add the forrest skinconf namespace
- Remove DTD
- use only RelaxNG validation for it
This should:
- Keep it extensible by namespacing
- Keep the stylesheets as are now
- Keep validation (as RelaxNG IIRC runs on namespaces)
- Make it loadable by XmlProperty
What do others think, is this the right mix?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>
> Yes, with validation switched off they are equipollent, but weren't you
> in favor of validation?
>
Yes I am in favour of validation, This is an example to show you that
you proposal and our current state without validation is equivalent.
> Let's assume that we, as you suggest IIUC, turn off DTD validation... we
> would have the same format we have now, that is simpler to read, but
> without editor DTD help... basically what is now in the copyless branch,
> right?
>
no, I am not suggesting turning off validation, I just do not want to
use your proposal but find a way to get non-standard features, so it can
be expanded.
>
> Ok, so here is my proposal: we remove the DTD declaration from the file
> so that it's not DTD-validated, but retain the current format. This will
> give us the possibility of testing the non-validation without changing
> too much. In advance we shall add a namespace declaration to the tags,
> so that users can easily see which tags are standard and which are not.
>
> So, if things start getting bad we can put the DTD or RelaxNG back in
> place with no trouble, if all goes well but users want a DTD for editors
> we change the format, and if all goes well we keep it without validation.
>
> Deal?
>
what about this:
elements under <skinconfig> becomes standard ones.
add <feature> elements under skincont like your prososal so it can be
use for non-standard features.
Adding this on the DTD should resolve it:
<!ELEMENT feature (element*)>
<!ATTLIST feature name CDATA #IMPLIED
value CDATA #IMPLIED>
<!ELEMENT element (property*)>
<!ATTLIST element name CDATA #IMPLIED>
<!ELEMENT property (#PCDATA)>
<!ATTLIST property name CDATA #IMPLIED>
Re: [VOTE] New skinconf format
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>>> can we find another way to extend the skinconfig?
>>
>> Tell me.
>
> "standard" forrest configuration is hold under skinconf.xml, other can
> be on a diferent file, then a transformation mix them out and put them
> under {project.webapp}/skinconf.xml
>
> This transformation could be on build time or run time.
Hmmm, yes we can also do it at runtime with the copyless stuff.
Hmmm... it separates standard and not-standard features... maybe we
should really add a namespace to the elements...
>>> When you suggest to have a DTD that does not change, this implies
>>> that the only thing that check is that the document is xml, so we are
>>> better of turn it on validation off and remove the DTD reference from
>>> the file.
>>
>> It's not correct, as the DTD helps in editing the file with an editor
>> that hints the tags.
>
> But because you want to make it more complex:
>
> If you said that on our skinconf each element is a feature, these two
> elements are the same:
>
> <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>
>
> <logo name="forrest" url="http://xml.apache.org/forrest"
> logo="images/project-logo.gif" />
>
>
> If you want to group features then you have to:
>
> <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>
> <feature/>
>
>
> That is the same as
>
> <credits>
> <element name="Built with Cocoon" url="http://xml.apache.org/cocoon/"
> image="images/built-with-cocoon.gif" width="88" height="31"/>
> <credits>
>
> But with validation switch it off.
>
> Am I right?
Yes, with validation switched off they are equipollent, but weren't you
in favor of validation?
Let's assume that we, as you suggest IIUC, turn off DTD validation... we
would have the same format we have now, that is simpler to read, but
without editor DTD help... basically what is now in the copyless branch,
right?
>>
>> In any case, it's useless to go on like this when we both understand
>> the points of the other. What I'm asking to vote for is a compromise
>> between fixed values and a more lax system. The other votes I've seen
>> are +1, what is yours?
>
> I am on -0
Ok, so here is my proposal: we remove the DTD declaration from the file
so that it's not DTD-validated, but retain the current format. This will
give us the possibility of testing the non-validation without changing
too much. In advance we shall add a namespace declaration to the tags,
so that users can easily see which tags are standard and which are not.
So, if things start getting bad we can put the DTD or RelaxNG back in
place with no trouble, if all goes well but users want a DTD for editors
we change the format, and if all goes well we keep it without validation.
Deal?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>>
>> can we find another way to extend the skinconfig?
>
>
> Tell me.
>
"standard" forrest configuration is hold under skinconf.xml, other can
be on a diferent file, then a transformation mix them out and put them
under {project.webapp}/skinconf.xml
This transformation could be on build time or run time.
>> When you suggest to have a DTD that does not change, this implies that
>> the only thing that check is that the document is xml, so we are
>> better of turn it on validation off and remove the DTD reference from
>> the file.
>
>
> It's not correct, as the DTD helps in editing the file with an editor
> that hints the tags.
>
But because you want to make it more complex:
If you said that on our skinconf each element is a feature, these two
elements are the same:
<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>
<logo name="forrest" url="http://xml.apache.org/forrest"
logo="images/project-logo.gif" />
If you want to group features then you have to:
<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>
<feature/>
That is the same as
<credits>
<element name="Built with Cocoon" url="http://xml.apache.org/cocoon/"
image="images/built-with-cocoon.gif" width="88" height="31"/>
<credits>
But with validation switch it off.
Am I right?
>
> In any case, it's useless to go on like this when we both understand the
> points of the other. What I'm asking to vote for is a compromise between
> fixed values and a more lax system. The other votes I've seen are +1,
> what is yours?
>
I am on -0
Re: [VOTE] New skinconf format
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>> The problem is that if a user does not enter a value, we can detect it
>> only if we make it mandatory. If it's not mandatory, the user can also
>> not put it in.
>
> I am not requesting put values mandatory, but avoiding putting wrong
> values.
We all know that this could happen, but I repeat that it is not a
problem with forrest.properties, is it?
>> The only thing we will be losing is the ability to tell the user that
>> some values are not correct, but in fact it's a feature, because that
>> particualr skin may want such values!
>
> ok, I know that you want to extend the skinconf for other skins but this
> requiered to turn validation off.
>
> can we find another way to extend the skinconfig?
Tell me.
>>> If the only proposal is to check for xml well formess then turn it
>>> validation off is enough.
>>
>> Sorry I don't understand.
>
> When you suggest to have a DTD that does not change, this implies that
> the only thing that check is that the document is xml, so we are better
> of turn it on validation off and remove the DTD reference from the file.
It's not correct, as the DTD helps in editing the file with an editor
that hints the tags.
>>>> We would loose a benefit but gain others. IMHO the gains are much
>>>> bigger, especially seeing how the current system has not worked too
>>>> well.
>>>
>>> could you expand on what actually has not worked too well?
>>
>> Upgrading, both for us and for the users.
>>
>> Usually when i add a value to skinconf I put it in the fresh-site and
>> document it. But then it has happened more than once that we forgot to
>> update the skinconf DTD or the relaxNG one, and Forrest was broken.
>
> But, when you said that forrest is broken because the validation
> complains is a feature. It helps to find *our* errors. Man, I am having
> the feeling that you want us to remove our seat belt.
It has never helped us find our errors AFAIK. IIRC the error was that we
did not update the DTD ;-)
>> Worse yet, users have to manually fix their skinconf DTD each time,
>> and there are many many mails from Adam from Gump that show plainly
>> how he could not get Forrest to work well, even if there was a DTD in
>> place.
>
> But this was because <!DOCTYPE and the ENTITY was in the skinconf file
> but this is not the case anymore. This has been fixed already.
Conceded, but still with the DTD we will have to upgrade files every
time, unless we don't version the DTD, which is not a nice thing to do.
It's not fail-fast.
In any case, it's useless to go on like this when we both understand the
points of the other. What I'm asking to vote for is a compromise between
fixed values and a more lax system. The other votes I've seen are +1,
what is yours?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>
>
> The problem is that if a user does not enter a value, we can detect it
> only if we make it mandatory. If it's not mandatory, the user can also
> not put it in.
>
I am not requesting put values mandatory, but avoiding putting wrong values.
> The only thing we will be losing is the ability to tell the user that
> some values are not correct, but in fact it's a feature, because that
> particualr skin may want such values!
>
ok, I know that you want to extend the skinconf for other skins but this
requiered to turn validation off.
can we find another way to extend the skinconfig?
>> If the only proposal is to check for xml well formess then turn it
>> validation off is enough.
>
>
> Sorry I don't understand.
>
When you suggest to have a DTD that does not change, this implies that
the only thing that check is that the document is xml, so we are better
of turn it on validation off and remove the DTD reference from the file.
>>> We would loose a benefit but gain others. IMHO the gains are much
>>> bigger, especially seeing how the current system has not worked too
>>> well.
>>
>>
>> could you expand on what actually has not worked too well?
>
>
> Upgrading, both for us and for the users.
>
> Usually when i add a value to skinconf I put it in the fresh-site and
> document it. But then it has happened more than once that we forgot to
> update the skinconf DTD or the relaxNG one, and Forrest was broken.
>
But, when you said that forrest is broken because the validation
complains is a feature. It helps to find *our* errors. Man, I am having
the feeling that you want us to remove our seat belt.
> Worse yet, users have to manually fix their skinconf DTD each time, and
> there are many many mails from Adam from Gump that show plainly how he
> could not get Forrest to work well, even if there was a DTD in place.
>
But this was because <!DOCTYPE and the ENTITY was in the skinconf file
but this is not the case anymore. This has been fixed already.
Re: [VOTE] New skinconf format
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>>>
>>> So what will be the output without all the skinconf elements?
>>
>> Good question, easy answer.
>>
>> The search box should search the whole web, the skinconf trail should
>> not show, the header should not even appear, the colors are of the
>> standard theme for the skin, etc...
>
> Well, I do not feel that this is right, all the element should behave in
> the same way, so If we remove the search element, then it should not
> appear on the site.
Correct, I was erroneously thinking of removing the search properties.
<feature name="search" value="true"/>
This should show a generic search.
[none]
or
<feature name="search" value="false"/>
should not show search.
>>> If the DTD will not change is because it does not validate for the
>>> elements say:
>>>
>>> <feature name="search" value="true">
>>> <property name="foo">xml.apache.org</property>
>>> <property name="morefoo">Apache XML</property>
>>> </feature>
>>>
>>> On a skin there is a expectation for
>>> feature[@name='search']/property/attribute::name
>>>
>>> So it will not work and it will not display xml.apache.org
>>
>> Correct, it will not work, as the names of the parameters are wrong. I
>> don't think it's too difficult to understand for the user: feature not
>> working == params not correct.
>
> But would not be better to detect this problem before?
The problem is that if a user does not enter a value, we can detect it
only if we make it mandatory. If it's not mandatory, the user can also
not put it in.
The only thing we will be losing is the ability to tell the user that
some values are not correct, but in fact it's a feature, because that
particualr skin may want such values!
> If the only
> proposal is to check for xml well formess then turn it validation off is
> enough.
Sorry I don't understand.
>> We would loose a benefit but gain others. IMHO the gains are much
>> bigger, especially seeing how the current system has not worked too well.
>
> could you expand on what actually has not worked too well?
Upgrading, both for us and for the users.
Usually when i add a value to skinconf I put it in the fresh-site and
document it. But then it has happened more than once that we forgot to
update the skinconf DTD or the relaxNG one, and Forrest was broken.
Worse yet, users have to manually fix their skinconf DTD each time, and
there are many many mails from Adam from Gump that show plainly how he
could not get Forrest to work well, even if there was a DTD in place.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>>
>> So what will be the output without all the skinconf elements?
>
>
> Good question, easy answer.
>
> The search box should search the whole web, the skinconf trail should
> not show, the header should not even appear, the colors are of the
> standard theme for the skin, etc...
>
Well, I do not feel that this is right, all the element should behave in
the same way, so If we remove the search element, then it should not
appear on the site.
>> If the DTD will not change is because it does not validate for the
>> elements say:
>>
>> <feature name="search" value="true">
>> <property name="foo">xml.apache.org</property>
>> <property name="morefoo">Apache XML</property>
>> </feature>
>>
>> On a skin there is a expectation for
>> feature[@name='search']/property/attribute::name
>>
>> So it will not work and it will not display xml.apache.org
>
>
> Correct, it will not work, as the names of the parameters are wrong. I
> don't think it's too difficult to understand for the user: feature not
> working == params not correct.
>
But would not be better to detect this problem before?, If the only
proposal is to check for xml well formess then turn it validation off is
enough.
> We would loose a benefit but gain others. IMHO the gains are much
> bigger, especially seeing how the current system has not worked too well.
>
could you expand on what actually has not worked too well?
Cheers,
Cheche
Re: [VOTE] New skinconf format
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola Ken Barozzi escribió:
>
>>
>> Here is the proposal:
>>
>> * Forrest should work also without any skinconf element: skinconf
>> elements are just hints, that a skin can decide not to follow
>> (as it happens already actually, just that the DTD makes people think
>> that Forrest will necessarily honor all hints)
>>
>
> So what will be the output without all the skinconf elements?
Good question, easy answer.
The search box should search the whole web, the skinconf trail should
not show, the header should not even appear, the colors are of the
standard theme for the skin, etc...
>> In this way we get lax and extensible elements but reasonable editing.
>> The DTD will not change, so we can easily inline it in the XML, thus
>> making it trivial for validating editors to validate it (no catalogs
>> to set).
>
> If the DTD will not change is because it does not validate for the
> elements say:
>
> <feature name="search" value="true">
> <property name="foo">xml.apache.org</property>
> <property name="morefoo">Apache XML</property>
> </feature>
>
> On a skin there is a expectation for
> feature[@name='search']/property/attribute::name
>
> So it will not work and it will not display xml.apache.org
Correct, it will not work, as the names of the parameters are wrong. I
don't think it's too difficult to understand for the user: feature not
working == params not correct.
> I can see the beneficts, but I am not sure.
We would loose a benefit but gain others. IMHO the gains are much
bigger, especially seeing how the current system has not worked too well.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] New skinconf format
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola Ken Barozzi escribió:
>
> Here is the proposal:
>
> * Forrest should work also without any skinconf element: skinconf
> elements are just hints, that a skin can decide not to follow
> (as it happens already actually, just that the DTD makes people think
> that Forrest will necessarily honor all hints)
>
So what will be the output without all the skinconf elements?
>
> In this way we get lax and extensible elements but reasonable editing.
> The DTD will not change, so we can easily inline it in the XML, thus
> making it trivial for validating editors to validate it (no catalogs to
> set).
If the DTD will not change is because it does not validate for the
elements say:
<feature name="search" value="true">
<property name="foo">xml.apache.org</property>
<property name="morefoo">Apache XML</property>
</feature>
On a skin there is a expectation for
feature[@name='search']/property/attribute::name
So it will not work and it will not display xml.apache.org
I can see the beneficts, but I am not sure.
Cheers,
Cheche
>
> In this way we will have a simple skinconf DTD, that is both extensible
> and formally validated.
>
> +1
>
Re: [VOTE] New skinconf format
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
> The latest happenings on skinconf have brought me to consider a format
> for skinconf.xml.
>
> Here is the proposal:
>
> * Forrest should work also without any skinconf element: skinconf
> elements are just hints, that a skin can decide not to follow
> (as it happens already actually, just that the DTD makes people think
> that Forrest will necessarily honor all hints)
>
> * there is a simple DTD used as a structure (see below)
>
> * 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
>
> Here is a proposed skinconf:
>
+1 for it all
> In this way we will have a simple skinconf DTD, that is both extensible
> and formally validated.
>
> +1
>
> --
> 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
Re: [VOTE] New skinconf format
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
<snip/>
>
> In this way we get lax and extensible elements but reasonable editing.
> The DTD will not change, so we can easily inline it in the XML, thus
> making it trivial for validating editors to validate it (no catalogs to
> set).
>
> In this way we will have a simple skinconf DTD, that is both extensible
> and formally validated.
>
> +1
+1 from me. As Cheche said, we do lose something important
with the old ability to ensure that parameter names are correct.
However, i am prepared to try this approach. We can always develop
some additional validation method, now that we do not trip up on
a complex DTD.
--David