You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "N. Sean Timm" <st...@mailgo.com> on 2000/07/03 00:44:59 UTC
[PATCH] Sitemap Draft - Misc. fixes and preliminary schema
I've included a diff inline for some changes to the sitemap draft document.
One of the changes involved declaring namespaces for all of the parameters
for each component. This was rather annoying (to me), and I think I'd
personally rather see something along the lines of <param name="foo"
value="bar"/>, but maybe there is a good reason for why it is the way it is.
Besides the miscellaneous fixes, I've attached a preliminary sitemap schema
based on the latest draft. The schema is not complete yet, and, thus, won't
quite validate correctly. I've gotten it up to the complicated part inside
the pipeline, but now I've found that my lack of schema knowledge is
severely slowing progress. I thought I'd throw what I had up to the list in
case someone was more familiar than I was with schemas and wanted to give it
a go. Otherwise, I'll keep plugging away at it, but it may take a little
longer trying to figure out this last part.
I'm sure I've done some things wrong, but hopefully this is a good start on
it...
- Sean T.
------------------------------
Index: sitemap-working-draft.xmap
===================================================================
RCS file:
/home/cvspublic/xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xmap,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 sitemap-working-draft.xmap
--- sitemap-working-draft.xmap 2000/06/30 17:21:31 1.1.2.5
+++ sitemap-working-draft.xmap 2000/07/02 22:32:45
@@ -117,7 +117,13 @@
============================================================================
-->
-<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
+<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0"
+ xmlns:xslparams="http://apache.org/cocoon/params/xalan/1.0"
+
xmlns:serializeparams="http://apache.org/cocoon/params/serialize/1.0"
+ xmlns:svgparams="http://apache.org/cocoon/params/svg/1.0"
+ xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
+ xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0
+ sitemap-working-draft.xsd">
<!-- =========================== Components
================================ -->
@@ -140,7 +146,7 @@
-->
<map:transformers default="xslt">
<map:transformer type="xslt"
src="class:///org.apache.cocoon.transformer.XSLTTransformer">
- <compile-stylesheets map:value="true"/>
+ <xslparams:compile-stylesheets map:value="true"/>
</map:transformer>
<map:transformer type="xinclude"
src="class:///org.apache.cocoon.transformer.XIncludeTransformer"
label="content"/>
<map:transformer type="schema"
src="class:///org.apache.cocoon.transformer.SchemaLoader"/>
@@ -153,28 +159,28 @@
-->
<map:serializers default="html">
<map:serializer type="html" mime-type="text/html"
src="class:///org.apache.cocoon.serializer.HTMLSerializer">
- <doctype-public map:value="-//W3C//DTD HTML 4.0 Transitional//EN"/>
- <doctype-system map:value="http://www.w3.org/TR/REC-html40/loose.dtd"/>
- <preserve-space map:value="true"/>
- <encoding map:value="UTF-8"/>
- <indent map:value="1"/>
- <line-width map:value="120"/>
+ <serializeparams:doctype-public map:value="-//W3C//DTD HTML 4.0
Transitional//EN"/>
+ <serializeparams:doctype-system
map:value="http://www.w3.org/TR/REC-html40/loose.dtd"/>
+ <serializeparams:preserve-space map:value="true"/>
+ <serializeparams:encoding map:value="UTF-8"/>
+ <serializeparams:indent map:value="1"/>
+ <serializeparams:line-width map:value="120"/>
</map:serializer>
<map:serializer type="wap" mime-type="text/vnd.wap.wml"
src="class:///org.apache.cocoon.serializer.XMLSerializer">
- <doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public>
-
<doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system>
- <encoding>UTF-8</encoding>
+ <serializeparams:doctype-public>-//WAPFORUM//DTD WML
1.1//EN</serializeparams:doctype-public>
+
<serializeparams:doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</ser
ializeparams:doctype-system>
+ <serializeparams:encoding>UTF-8</serializeparams:encoding>
</map:serializer>
<map:serializer type="svg2jpg" mime-type="image/jpg"
src="class:///org.apache.cocoon.serializer.SVGSerializer">
- <format map:value="jpg"/>
- <compression-level>80%</compression-level>
+ <svgparams:format map:value="jpg"/>
+ <svgparams:compression-level>80%</svgparams:compression-level>
</map:serializer>
<map:serializer type="svg2png" mime-type="image/png"
src="class:///org.apache.cocoon.serializer.SVGSerializer">
- <format>png</format>
- <color-depth map:value="24"/>
+ <svgparams:format>png</svgparams:format>
+ <svgparams:color-depth map:value="24"/>
</map:serializer>
</map:serializers>
@@ -403,7 +409,7 @@
Example to show the notion of pipeline labels for view generation.
-->
<map:match pattern="labelled/*">
- <map:label name="links"
+ <map:label name="links">
<map:label name="content">
<map:generate src="./slides/{1}"/>
</map:label>
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Jonathan Stimmel <jo...@stimmel.net>.
On Mon, Jul 03, 2000 at 09:01:21AM +0200, Giacomo Pati wrote:
> If somebody _has_ a good reason he should explain why. Else I would
> suggest going to <map:param> to keep at least the coding of a sitemap as
> simple as possible.
I am inclined to agree with using <map:param>, though perhaps we could
get some additional mileage by adding the ability to specify multi-valued
parameters? For instance, if you had a component that needed to load-balance
across several servers:
<map:paramlist name="server">
<map:param value="server1.myco.com"/>
<map:param value="server2.myco.com"/>
<map:param value="server3.myco.com"/>
</map:param>
Or would this be implicit in:
<map:param name="server" value="server1.myco.com"/>
<map:param name="server" value="server2.myco.com"/>
<map:param name="server" value="server3.myco.com"/>
?
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Niclas Hedhman <ni...@localbar.com>.
Giacomo Pati wrote:
> If somebody _has_ a good reason he should explain why. Else I would
> suggest going to <map:param> to keep at least the coding of a sitemap as
> simple as possible.
> I would not apply this patch for now (no offense to you, Sean, thank you
> for your work)
I disagree of the 'procedural variable' approach. It is a far step backward as
far as I see it. You automatically introduce a limitation that I think is both
ugly and counter productive.
Just for the sake of it;
Assume I make a SVG charting component as a resource. If you have used any
servlet or applet based charting you should know how massive the <param> tags
become, and how the names are cascaded with dots, and God knows what to line up
long sets of settings.
If we have XML, we use it!!! Otherwise we could go back and do it with Properties
files.
Niclas
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by "N. Sean Timm" <st...@mailgo.com>.
"Giacomo Pati" <Gi...@pwr.ch> wrote:
> > I've included a diff inline for some changes to the sitemap draft
document.
> > One of the changes involved declaring namespaces for all of the
parameters
> > for each component. This was rather annoying (to me), and I think I'd
> > personally rather see something along the lines of <param name="foo"
> > value="bar"/>, but maybe there is a good reason for why it is the way it
is.
>
> If somebody _has_ a good reason he should explain why. Else I would
> suggest going to <map:param> to keep at least the coding of a sitemap as
> simple as possible.
> I would not apply this patch for now (no offense to you, Sean, thank you
> for your work)
>
None taken. :) Actually, I rather hoped that people wouldn't want to
commit it after seeing how ugly the param namespace thing was. :) I'm +1
on switching to map:param unless we hear from someone that knows better.
- Sean T.
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Giacomo Pati <Gi...@pwr.ch>.
"N. Sean Timm" wrote:
>
> I've included a diff inline for some changes to the sitemap draft document.
> One of the changes involved declaring namespaces for all of the parameters
> for each component. This was rather annoying (to me), and I think I'd
> personally rather see something along the lines of <param name="foo"
> value="bar"/>, but maybe there is a good reason for why it is the way it is.
If somebody _has_ a good reason he should explain why. Else I would
suggest going to <map:param> to keep at least the coding of a sitemap as
simple as possible.
I would not apply this patch for now (no offense to you, Sean, thank you
for your work)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> "N. Sean Timm" wrote:
>
> > > One might argue that this is necessary or even recommendable (introduction
> > of
> > > more complexity).
> > If you're going to have a <doc-type> node, I think it either needs to reside
> > in some sort of parameter namespace (which seems messy), or you should have
> > to specify it like the following:
> >
> > <map:param name="doc-type" map:value="bac.dtd"/>
> > or
> > <map:param name="doc-type">bac.dtd</map:param>
>
> Do I?? I must admit that I don't comprehend the Namespace idea to its fullest,
> and I often am mistaken between name space, default name space and resulting
> name space (XSLT).
>
> So someone who is a bit more versed in these things, please work out the
> following dilemma.
>
> The Site map needs the flexibility to add components that have their own
> configuration structure.
> For instance;
> <map:chooser type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser">
> <param name="order" value="allow,deny" />
> <param name="all" value="false" />
> <allow host="com" />
> <allow host="com.my" />
> <allow host="se" />
> <deny host="controller.asiaconnect.com.my" />
> </map:chooser>
Yuch. There is no need to "clone" http.conf syntax, we have structure
and order, let's use it!
<map:chooser type="clientaddress" src="...">
<allow>
<host>com</host>
<host map:value="com.my"/>
<host>se</host>
</allow>
<deny>
<host>controller.asiaconnect.com.my</host>
</deny>
</map:chooser>
> Would that mean, to avoid all the possible collisions, and use of XSLT and
> other things, I would need to declare a namespace so that the above instead
> look like;
> <map:chooser
> type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
> xmlns:cac="http://apache.org/cocoon/components/chooser/ClientAddress"
> >
> <cac:param name="order" value="allow,deny" />
> <cac:param name="all" value="false" />
> <cac:allow host="com" />
> <cac:allow host="com.my" />
> <cac:allow host="se" />
> <cac:deny host="controller.asiaconnect.com.my" />
> </map:chooser>
>
> (The attributes would default to the tag name space, no?)
>
> And I could reduce that with a default namespace;
> <map:chooser
> type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
> xmlns="http://apache.org/cocoon/components/chooser/ClientAddress"
> >
> <param name="order" value="allow,deny" />
> <param name="all" value="false" />
> <allow host="com" />
> <allow host="com.my" />
> <allow host="se" />
> <deny host="controller.asiaconnect.com.my" />
> </map:chooser>
>
> Now, since at least the latter two is equivalent (as I understand NS), how
> would this affect the Configurations in Cocoon.
> I have noticed that I need to do a
> Enumeration list=conf.getConfigurations( "map:choosers" );
> But, what if the map: prefix is changed (not likely for the sitemap in general,
> but for smaller components yes.)
> Enumeration list = conf.getConfigurations("cac:allow");
> Only works if cac, is used. How do I proceed when the declaration is in the
> default NS, and so on...?
> Do I look it up?
Your approach to namespaces is mechanical. A namespace is "not" part of
the name. In a namespace-aware configuration you would ask for
Configuration conf = getConfigurations("choosers",
"http://mynamespace");
Anyway, since having namespace-aware configuration is (for what I can
see now) useless, I'd say we keep the default namespace for anything
that should not be touched by the sitemap.
This is why "value" is in the sitemap namespace: it should be
transparent to the Configuration objects passed to components.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Niclas Hedhman <ni...@localbar.com>.
"N. Sean Timm" wrote:
> > One might argue that this is necessary or even recommendable (introduction
> of
> > more complexity).
> If you're going to have a <doc-type> node, I think it either needs to reside
> in some sort of parameter namespace (which seems messy), or you should have
> to specify it like the following:
>
> <map:param name="doc-type" map:value="bac.dtd"/>
> or
> <map:param name="doc-type">bac.dtd</map:param>
Do I?? I must admit that I don't comprehend the Namespace idea to its fullest,
and I often am mistaken between name space, default name space and resulting
name space (XSLT).
So someone who is a bit more versed in these things, please work out the
following dilemma.
The Site map needs the flexibility to add components that have their own
configuration structure.
For instance;
<map:chooser type="clientaddress"
src="class:///org.apache.cocoon.choosers.ClientAddressChooser">
<param name="order" value="allow,deny" />
<param name="all" value="false" />
<allow host="com" />
<allow host="com.my" />
<allow host="se" />
<deny host="controller.asiaconnect.com.my" />
</map:chooser>
Would that mean, to avoid all the possible collisions, and use of XSLT and
other things, I would need to declare a namespace so that the above instead
look like;
<map:chooser
type="clientaddress"
src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
xmlns:cac="http://apache.org/cocoon/components/chooser/ClientAddress"
>
<cac:param name="order" value="allow,deny" />
<cac:param name="all" value="false" />
<cac:allow host="com" />
<cac:allow host="com.my" />
<cac:allow host="se" />
<cac:deny host="controller.asiaconnect.com.my" />
</map:chooser>
(The attributes would default to the tag name space, no?)
And I could reduce that with a default namespace;
<map:chooser
type="clientaddress"
src="class:///org.apache.cocoon.choosers.ClientAddressChooser"
xmlns="http://apache.org/cocoon/components/chooser/ClientAddress"
>
<param name="order" value="allow,deny" />
<param name="all" value="false" />
<allow host="com" />
<allow host="com.my" />
<allow host="se" />
<deny host="controller.asiaconnect.com.my" />
</map:chooser>
Now, since at least the latter two is equivalent (as I understand NS), how
would this affect the Configurations in Cocoon.
I have noticed that I need to do a
Enumeration list=conf.getConfigurations( "map:choosers" );
But, what if the map: prefix is changed (not likely for the sitemap in general,
but for smaller components yes.)
Enumeration list = conf.getConfigurations("cac:allow");
Only works if cac, is used. How do I proceed when the declaration is in the
default NS, and so on...?
Do I look it up?
Niclas
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Giacomo Pati <Gi...@pwr.ch>.
"N. Sean Timm" wrote:
>
> "Niclas Hedhman" <ni...@localbar.com> wrote:
> >
> > One might argue that this is necessary or even recommendable (introduction
> > of
> > more complexity).
> If you're going to have a <doc-type> node, I think it either needs to reside
> in some sort of parameter namespace (which seems messy), or you should have
> to specify it like the following:
>
> <map:param name="doc-type" map:value="bac.dtd"/>
> or
> <map:param name="doc-type">bac.dtd</map:param>
+1 on that
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Stefano Mazzocchi <st...@apache.org>.
"N. Sean Timm" wrote:
>
> "Stefano Mazzocchi" <st...@apache.org> wrote:
> > > If you're going to have a <doc-type> node, I think it either needs to
> reside
> > > in some sort of parameter namespace (which seems messy), or you should
> have
> > > to specify it like the following:
> > >
> > > <map:param name="doc-type" map:value="bac.dtd"/>
> > > or
> > > <map:param name="doc-type">bac.dtd</map:param>
> >
> > Sean, I don't see your problem with
> >
> > <doc-type map:value="bad.dtd"/>
> > <doc-type>bac.dtd</doc-type>
> >
> > Each component will have access to configurations and namespaces don't
> > make it any simpler nor more powerful.
> >
> > I vote -1 to adding a new namespace for each component. The sitemap will
> > "consume" its namespace and make available to components everything
> > else.
> >
> > I don't see any problem with this.
>
> During my initial schema work, I came under the impression that those
> parameters *had* to be declared in a namespace in order to create a schema
> at all. I see now that this is not the case. So, yes, we could allow
> anything in the default namespace as parameters. The only consequence is
> that all parameter names/values will not be able to be validated against a
> schema.
Of course, that's the point.
> I like the idea of being able to validate the entire sitemap
> against a schema while I'm developing it.
??? careful: "validation" is the act of saying if some file is valid or
not.
When your component does:
conf.getConfiguration(String path, bookean required);
and the required configuration is not there, this is a validation
problem.
You clearly showed how complex a sitemap becomes if you use XSchema to
validate everything... and how unbalanced it might become later on when
you add your components and you have to ask for "namespace granting"
around here.
Here, you simply place your own validation inside your logic and the
Avalon classes will provide ways to make it so simply you don't even
know you are actually validating something while using it.
Cocoon could also be run from the command line in "sitemap validation
mode", just like Apache can.
> It would certainly help prevent certain simple (but stupid) mistakes.
Oh, please don't forget that DTD and XSchema are just two of the
infinite possible ways to validate a document. The first works ok with
mono-dimensional XML documents, the second is more complex but still
very limited compared to any turing-complete language.
> On the other hand...doing it like
> I suggested (ie. <map:param name="foo" value="bar"/> wouldn't allow
> parameter validation, either.
Yes.
> Like I mentioned, I didn't like declaring
> namespaces for the parameters, either, but it's the only way to validate the
> parameters. Is this something anyone cares about? I'm rather ambivalent at
> this point, so I'm curious if anyone else feels that schema-based parameter
> validation is important. If not, then the default namespace works just
> great.
It's not a matter of "caring about validation", of course we all care to
see Cocoon say "hey, I need this parameter here"!
The point is: should XMLSchema take care of all possible cases?
My (pretty strong) answer is no.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by "N. Sean Timm" <st...@mailgo.com>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> > If you're going to have a <doc-type> node, I think it either needs to
reside
> > in some sort of parameter namespace (which seems messy), or you should
have
> > to specify it like the following:
> >
> > <map:param name="doc-type" map:value="bac.dtd"/>
> > or
> > <map:param name="doc-type">bac.dtd</map:param>
>
> Sean, I don't see your problem with
>
> <doc-type map:value="bad.dtd"/>
> <doc-type>bac.dtd</doc-type>
>
> Each component will have access to configurations and namespaces don't
> make it any simpler nor more powerful.
>
> I vote -1 to adding a new namespace for each component. The sitemap will
> "consume" its namespace and make available to components everything
> else.
>
> I don't see any problem with this.
During my initial schema work, I came under the impression that those
parameters *had* to be declared in a namespace in order to create a schema
at all. I see now that this is not the case. So, yes, we could allow
anything in the default namespace as parameters. The only consequence is
that all parameter names/values will not be able to be validated against a
schema. I like the idea of being able to validate the entire sitemap
against a schema while I'm developing it. It would certainly help prevent
certain simple (but stupid) mistakes. :) On the other hand...doing it like
I suggested (ie. <map:param name="foo" value="bar"/> wouldn't allow
parameter validation, either. Like I mentioned, I didn't like declaring
namespaces for the parameters, either, but it's the only way to validate the
parameters. Is this something anyone cares about? I'm rather ambivalent at
this point, so I'm curious if anyone else feels that schema-based parameter
validation is important. If not, then the default namespace works just
great.
- Sean T.
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Stefano Mazzocchi <st...@apache.org>.
"N. Sean Timm" wrote:
>
> "Niclas Hedhman" <ni...@localbar.com> wrote:
> > > I've included a diff inline for some changes to the sitemap draft
> document.
> > > One of the changes involved declaring namespaces for all of the
> parameters
> > > for each component. This was rather annoying (to me), and I think I'd
> > > personally rather see something along the lines of <param name="foo"
> > > value="bar"/>, but maybe there is a good reason for why it is the way it
> is.
> >
> > The <serializeparams> and <svgparams>
> > -1.
> > The map: namespace for the attributes (I believe) is for making the
> equivalence
> > between;
> >
> > <doc-type map:value="bac.dtd" />
> > and
> > <doc-type>bac.dtd</doc-type>
> But any custom transformer or serializer you write that isn't part of the
> base Cocoon distribution won't be a part of the map namespace. Why should
> the ones that come with Cocoon be any different?
I totally agree, this is why they didn't have any namespaces specified.
> I don't like the idea that
> those parameters can reside in the map namespace while others have to be
> separate. It just doesn't seem right...anyway, with the examples in the
> sitemap draft, they weren't in the map namespace (the values were, but not
> the parameter name).
The values are different, because this is a special attribute that is
reserved.
> > One might argue that this is necessary or even recommendable (introduction
> of
> > more complexity).
> If you're going to have a <doc-type> node, I think it either needs to reside
> in some sort of parameter namespace (which seems messy), or you should have
> to specify it like the following:
>
> <map:param name="doc-type" map:value="bac.dtd"/>
> or
> <map:param name="doc-type">bac.dtd</map:param>
Sean, I don't see your problem with
<doc-type map:value="bad.dtd"/>
<doc-type>bac.dtd</doc-type>
Each component will have access to configurations and namespaces don't
make it any simpler nor more powerful.
I vote -1 to adding a new namespace for each component. The sitemap will
"consume" its namespace and make available to components everything
else.
I don't see any problem with this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by "N. Sean Timm" <st...@mailgo.com>.
"Niclas Hedhman" <ni...@localbar.com> wrote:
> > I've included a diff inline for some changes to the sitemap draft
document.
> > One of the changes involved declaring namespaces for all of the
parameters
> > for each component. This was rather annoying (to me), and I think I'd
> > personally rather see something along the lines of <param name="foo"
> > value="bar"/>, but maybe there is a good reason for why it is the way it
is.
>
> The <serializeparams> and <svgparams>
> -1.
> The map: namespace for the attributes (I believe) is for making the
equivalence
> between;
>
> <doc-type map:value="bac.dtd" />
> and
> <doc-type>bac.dtd</doc-type>
But any custom transformer or serializer you write that isn't part of the
base Cocoon distribution won't be a part of the map namespace. Why should
the ones that come with Cocoon be any different? I don't like the idea that
those parameters can reside in the map namespace while others have to be
separate. It just doesn't seem right...anyway, with the examples in the
sitemap draft, they weren't in the map namespace (the values were, but not
the parameter name).
>
> One might argue that this is necessary or even recommendable (introduction
of
> more complexity).
If you're going to have a <doc-type> node, I think it either needs to reside
in some sort of parameter namespace (which seems messy), or you should have
to specify it like the following:
<map:param name="doc-type" map:value="bac.dtd"/>
or
<map:param name="doc-type">bac.dtd</map:param>
- Sean T.
Re: [PATCH] Sitemap Draft - Misc. fixes and preliminary schema
Posted by Niclas Hedhman <ni...@localbar.com>.
"N. Sean Timm" wrote:
> I've included a diff inline for some changes to the sitemap draft document.
> One of the changes involved declaring namespaces for all of the parameters
> for each component. This was rather annoying (to me), and I think I'd
> personally rather see something along the lines of <param name="foo"
> value="bar"/>, but maybe there is a good reason for why it is the way it is.
The <serializeparams> and <svgparams>
-1.
The map: namespace for the attributes (I believe) is for making the equivalence
between;
<doc-type map:value="bac.dtd" />
and
<doc-type>bac.dtd</doc-type>
One might argue that this is necessary or even recommendable (introduction of
more complexity).
Niclas