You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2002/07/26 11:13:58 UTC
grammar-based pipeline configuration [Re: doctype questions]
Ian Atkin wrote:
> Steven Noels wrote:
>> One of the goals of Forrest is serious DTD change management. While
>> other projects consider XML grammars a bare necessity, we believe DTDs
>> are part of our deliverables. We actually enjoy working on these pesky
>> things - can you imagine?
>>
>> So yes, we believe people should refer to Forrest for 'reference' DTDs
>> - and we try to keep our DTDs as lean & mean as possible, while adding
>> relevant new elements/features upon request & evaluation.
>
>
>
> so part of forrest is to ship with a tightly constrained markup, and to
> encourage user projects to use it - ok
>
> question still remains that if someone doesn't like/know this markup can
> they still use forrest? looks like answer is no
I have been thinking about this since Cocoon1 time... the SoC enforced
using Cocoon2 meant that you didn't directly referred from a document to
its accompagnying stylesheet, but used a sitemap instead.
Now this is very good practice etc... but this also means the grammar
against which your documents validate, is only used during document
creation, and cannot be used for confugation during generation/rendition.
Imagine we want to support several document types (grammars, DTDs, XSDs,
you name it) with Forrest. A practical example of this is the work Diana
did once during some transition test from doc-v10 to doc-v11. Another
example might be supporting DocBook with Forrest. You have a scenario
where the routing of documents across the Cocoon pipeline need to be
done based on the type/class of the document, and cannot be inferred
from the environment (request/context/etc)
We would have a situation like this:
<map:match pattern="*.html">
<map:generate src="*.xml">
<map:match public-id="-//APACHE//DTD FAQ V1.1//EN" type="doctypematcher">
<map:transform src="faq2document.xsl"/>
</map:match>
<map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
type="doctypematcher">
<map:transform src="faq2document.xsl"/>
</map:match>
<map:call resource="skinit">
<map:parameter name="type" value="document2html"/>
</map:call>
</map:match>
This brings us to the wonderful world of Martin Fowler's Two Step View
Pattern (http://martinfowler.com/isa/htmlRenderer.html), setting the
interface (logical page) of Forrest to an XML document that complies to
the document-v11 dtd, but giving the authors a choice of authoring
formats (doc-v11 being one of them, too).
In terms of implementation, this could be a pipeline configuration
component, a Matcher of Selector. It would require to 'parse' the XML
document upto a level it can detect its grammar (for DTDs the doctype
statement, for Schemas the xsi:SchemaLocation attribute, etc),
sufficiently cached etc...
What do you think of this approach? What do Cocooners think of it?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Sylvain Wallez wrote:
>
>> Steven Noels wrote
>>
>>> We would have a situation like this:
>>>
>>> <map:match pattern="*.html">
>>> <map:generate src="*.xml">
>>> <map:match public-id="-//APACHE//DTD FAQ V1.1//EN"
>>> type="doctypematcher">
>>> <map:transform src="faq2document.xsl"/>
>>> </map:match>
>>> <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
>>> type="doctypematcher">
>>> <map:transform src="docbook2document.xsl"/>
>>> </map:match>
>>> <map:call resource="skinit">
>>> <map:parameter name="type" value="document2html"/>
>>> </map:call>
>>> </map:match>
>>>
>
>> IMO, it's time to tackle this problem seriously, as there are many
>> use cases where pipeline construction is driven by what comes out
>> from its beginning : your DTDs above, SOAP requests, XForm
>> validations, etc.
>
>
> Thanks Sylvain.
>
> While a reference to a grammar is effectively hidden *inside* a
> document/SAX stream (on the LexicalHandler or ContentHandler level,
> depending whether it is a DTD reference or an XSD SchemaLocation
> attribute) - I interprete those as merily metadata to the document.
>
> I gather the proposed solution to this is suboptimal due to
> DOM-dependency? Why consider an Action to be more appropriate for this
> than a Matcher?
Quoting my own post, which was about selectors and not matchers :
>>
About separating the sensor and the valve by transmitting the
information outside the pipeline, I consider it as introducing a
"pipe-aware action". The main difference with a selector is that an
action doesn't necessarily change the pipe flow, and can do anything it
wants with the environment, including setting values used later by a
selector. So in this sense, this fits the need and is more versatile.
Also, since a pipe-aware action would have only one input and one ouput,
it would be easier to implement than a selector that has several
outputs, meaning we can have more easily some smart-buffering
implementations like mentioned above.
<<
A matcher is less limited in its possible results than a selector (it
can return sitemap variables), and the environmental data it has access
to is not far from the one available to an action.
So the choice betwen action and matcher is a semantic matter : a matcher
is supposed to perform a test, but not to change the system status. An
action can also perform tests (hence behaving like a matcher), but can
also modify the system status.
In your particular case, a matcher would be enough, but some use cases
will require an action.
Note also that "modifying the system status" doesn't mean modifying the
data flowing in the pipeline : this is the role of transformers.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> Steven Noels wrote
>> We would have a situation like this:
>>
>> <map:match pattern="*.html">
>> <map:generate src="*.xml">
>> <map:match public-id="-//APACHE//DTD FAQ V1.1//EN"
>> type="doctypematcher">
>> <map:transform src="faq2document.xsl"/>
>> </map:match>
>> <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
>> type="doctypematcher">
>> <map:transform src="docbook2document.xsl"/>
>> </map:match>
>> <map:call resource="skinit">
>> <map:parameter name="type" value="document2html"/>
>> </map:call>
>> </map:match>
>>
> IMO, it's time to tackle this problem seriously, as there are many use
> cases where pipeline construction is driven by what comes out from its
> beginning : your DTDs above, SOAP requests, XForm validations, etc.
Thanks Sylvain.
While a reference to a grammar is effectively hidden *inside* a
document/SAX stream (on the LexicalHandler or ContentHandler level,
depending whether it is a DTD reference or an XSD SchemaLocation
attribute) - I interprete those as merily metadata to the document.
I gather the proposed solution to this is suboptimal due to
DOM-dependency? Why consider an Action to be more appropriate for this
than a Matcher?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: grammar-based pipeline configuration [Re: doctype questions]
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Steven Noels wrote:
>
> > Ian Atkin wrote:
> >
> > > Steven Noels wrote:
> >
> >>> One of the goals of Forrest is serious DTD change management.
While
> >>> other projects consider XML grammars a bare necessity, we believe
> >>> DTDs are part of our deliverables. We actually enjoy working on
> >>> these pesky things - can you imagine?
> >>>
> >>> So yes, we believe people should refer to Forrest for 'reference'
> >>> DTDs - and we try to keep our DTDs as lean & mean as possible,
while
> >>> adding relevant new elements/features upon request & evaluation.
> >>
> >>
> >>
> >>
> >> so part of forrest is to ship with a tightly constrained markup,
and
> >> to encourage user projects to use it - ok
> >>
> >> question still remains that if someone doesn't like/know this
markup
> >> can they still use forrest? looks like answer is no
> >
> >
> > I have been thinking about this since Cocoon1 time... the SoC
enforced
> > using Cocoon2 meant that you didn't directly referred from a
document
> > to its accompagnying stylesheet, but used a sitemap instead.
> >
> > Now this is very good practice etc... but this also means the
grammar
> > against which your documents validate, is only used during document
> > creation, and cannot be used for confugation during
generation/rendition.
> >
> > Imagine we want to support several document types (grammars, DTDs,
> > XSDs, you name it) with Forrest. A practical example of this is the
> > work Diana did once during some transition test from doc-v10 to
> > doc-v11. Another example might be supporting DocBook with Forrest.
You
> > have a scenario where the routing of documents across the Cocoon
> > pipeline need to be done based on the type/class of the document,
and
> > cannot be inferred from the environment (request/context/etc)
> >
> > We would have a situation like this:
> >
> > <map:match pattern="*.html">
> > <map:generate src="*.xml">
> > <map:match public-id="-//APACHE//DTD FAQ V1.1//EN"
> > type="doctypematcher">
> > <map:transform src="faq2document.xsl"/>
> > </map:match>
> > <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
> > type="doctypematcher">
> > <map:transform src="faq2document.xsl"/>
> > </map:match>
> > <map:call resource="skinit">
> > <map:parameter name="type" value="document2html"/>
> > </map:call>
> > </map:match>
> >
> > This brings us to the wonderful world of Martin Fowler's Two Step
View
> > Pattern (http://martinfowler.com/isa/htmlRenderer.html), setting the
> > interface (logical page) of Forrest to an XML document that complies
> > to the document-v11 dtd, but giving the authors a choice of
authoring
> > formats (doc-v11 being one of them, too).
> >
> > In terms of implementation, this could be a pipeline configuration
> > component, a Matcher of Selector. It would require to 'parse' the
XML
> > document upto a level it can detect its grammar (for DTDs the
doctype
> > statement, for Schemas the xsi:SchemaLocation attribute, etc),
> > sufficiently cached etc...
> >
> > What do you think of this approach? What do Cocooners think of it?
>
>
> This is a really good use case for "pipe-aware" selectors and matchers
> which were proposed some time a go. Stefano gave a (temporary ?) -1 to
> them because he wanted some time to understand the architectural
> implications of such things.
> See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101735848009654&w=2
>
> This led to a RT at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101802546717014&w=2
to
> which I answered with "pipe-aware actions" at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101804111201995&w=2
>
> But all this led nowhere as there were many other subjects of interest
> at that time (mainly flow and form handling).
>
> IMO, it's time to tackle this problem seriously, as there are many use
> cases where pipeline construction is driven by what comes out from its
> beginning : your DTDs above, SOAP requests, XForm validations, etc.
Don't forget:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101318895229073&w=2
then follows:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101366633512443&w=2
and some of this is summarized here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101795181521729&w=2
PS I don't like name 'pipe-aware *selector*', 'pipe-aware *action*'.
IMHO, it smells bad:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101542313904156&w=2
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Ian Atkin wrote:
>
> > Steven Noels wrote:
>
>>> One of the goals of Forrest is serious DTD change management. While
>>> other projects consider XML grammars a bare necessity, we believe
>>> DTDs are part of our deliverables. We actually enjoy working on
>>> these pesky things - can you imagine?
>>>
>>> So yes, we believe people should refer to Forrest for 'reference'
>>> DTDs - and we try to keep our DTDs as lean & mean as possible, while
>>> adding relevant new elements/features upon request & evaluation.
>>
>>
>>
>>
>> so part of forrest is to ship with a tightly constrained markup, and
>> to encourage user projects to use it - ok
>>
>> question still remains that if someone doesn't like/know this markup
>> can they still use forrest? looks like answer is no
>
>
> I have been thinking about this since Cocoon1 time... the SoC enforced
> using Cocoon2 meant that you didn't directly referred from a document
> to its accompagnying stylesheet, but used a sitemap instead.
>
> Now this is very good practice etc... but this also means the grammar
> against which your documents validate, is only used during document
> creation, and cannot be used for confugation during generation/rendition.
>
> Imagine we want to support several document types (grammars, DTDs,
> XSDs, you name it) with Forrest. A practical example of this is the
> work Diana did once during some transition test from doc-v10 to
> doc-v11. Another example might be supporting DocBook with Forrest. You
> have a scenario where the routing of documents across the Cocoon
> pipeline need to be done based on the type/class of the document, and
> cannot be inferred from the environment (request/context/etc)
>
> We would have a situation like this:
>
> <map:match pattern="*.html">
> <map:generate src="*.xml">
> <map:match public-id="-//APACHE//DTD FAQ V1.1//EN"
> type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
> </map:match>
> <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
> type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
> </map:match>
> <map:call resource="skinit">
> <map:parameter name="type" value="document2html"/>
> </map:call>
> </map:match>
>
> This brings us to the wonderful world of Martin Fowler's Two Step View
> Pattern (http://martinfowler.com/isa/htmlRenderer.html), setting the
> interface (logical page) of Forrest to an XML document that complies
> to the document-v11 dtd, but giving the authors a choice of authoring
> formats (doc-v11 being one of them, too).
>
> In terms of implementation, this could be a pipeline configuration
> component, a Matcher of Selector. It would require to 'parse' the XML
> document upto a level it can detect its grammar (for DTDs the doctype
> statement, for Schemas the xsi:SchemaLocation attribute, etc),
> sufficiently cached etc...
>
> What do you think of this approach? What do Cocooners think of it?
This is a really good use case for "pipe-aware" selectors and matchers
which were proposed some time a go. Stefano gave a (temporary ?) -1 to
them because he wanted some time to understand the architectural
implications of such things.
See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101735848009654&w=2
This led to a RT at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101802546717014&w=2 to
which I answered with "pipe-aware actions" at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101804111201995&w=2
But all this led nowhere as there were many other subjects of interest
at that time (mainly flow and form handling).
IMO, it's time to tackle this problem seriously, as there are many use
cases where pipeline construction is driven by what comes out from its
beginning : your DTDs above, SOAP requests, XForm validations, etc.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
sorry, copy/paste error:
> We would have a situation like this:
>
> <map:match pattern="*.html">
> <map:generate src="*.xml">
> <map:match public-id="-//APACHE//DTD FAQ V1.1//EN" type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
> </map:match>
> <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
> type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
must be
> <map:transform src="docbook2document.xsl"/>
of course :-(
> </map:match>
> <map:call resource="skinit">
> <map:parameter name="type" value="document2html"/>
> </map:call>
> </map:match>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
sorry, copy/paste error:
> We would have a situation like this:
>
> <map:match pattern="*.html">
> <map:generate src="*.xml">
> <map:match public-id="-//APACHE//DTD FAQ V1.1//EN" type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
> </map:match>
> <map:match public-id="-//OASIS//DTD DocBook V3.1//EN"
> type="doctypematcher">
> <map:transform src="faq2document.xsl"/>
must be
> <map:transform src="docbook2document.xsl"/>
of course :-(
> </map:match>
> <map:call resource="skinit">
> <map:parameter name="type" value="document2html"/>
> </map:call>
> </map:match>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: [OT] Spam from GE
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 26.Jul.2002 -- 08:59 AM, Vadim Gritsenko wrote:
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> > Steven Noels wrote:
> > >
> > > Subject: ScanMail Message: To Sender, sensitive content found and
> > > action t aken.
> > > From: System Attendant <CI...@SUPPLY.GE.com>
> > >
> > > Trend SMEX Content Filter has detected sensitive content.
> > >
> > > Place = forrest-dev@xml.apache.org; cocoon-dev@xml.apache.org; ;
> > > cocoon-dev@xml.apache.org
> > > Policy = Matcher
> > > Action on this mail = Delete message
> >
> > I sometimes receive such messages, and never understood what triggers
> them.
> > My brain filter detects it as garbage content. Action on this mail =
> > Delete message also ;-)
>
> Do you know is it possible to stop these spammers? May be we shall get
> all these messages and send them back to GE IT?
I've tried to contact a person in charge of this a couple of times -
to no avail.
Is there a way to find the person(s) at ge.com that is subscribed to
this list, so that (s)he can talk to the administrators in charge?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[OT] Spam from GE, Was: grammar-based pipeline configuration [Re: doctype questions]
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Steven Noels wrote:
>
> > Steven Noels wrote:
> >
> > now this is funny... (a reply I received on my posting)
> >
> > are there any english words I'm using frequently that are considered
> > 'sensitive' by native speakers?? please help me :-)
> >
> > -------- Original Message --------
> > Subject: ScanMail Message: To Sender, sensitive content found and
> > action t aken.
> > Date: Fri, 26 Jul 2002 05:14:26 -0400
> > From: System Attendant <CI...@SUPPLY.GE.com>
> > To: "'Steven Noels'" <st...@outerthought.org>
> >
> > Trend SMEX Content Filter has detected sensitive content.
> >
> > Place = forrest-dev@xml.apache.org; cocoon-dev@xml.apache.org; ;
> > cocoon-dev@xml.apache.org
> > Sender = Steven Noels
> > Subject = grammar-based pipeline configuration [Re: doctype
questions]
> > Delivery Time = July 26, 2002 (Friday) 05:14:25
> > Policy = Matcher
> > Action on this mail = Delete message
>
>
> I sometimes receive such messages, and never understood what triggers
them.
> My brain filter detects it as garbage content. Action on this mail =
> Delete message also ;-)
Do you know is it possible to stop these spammers? May be we shall get
all these messages and send them back to GE IT?
PS I also can't get whose brains are in these filters...
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Steven Noels wrote:
>
> now this is funny... (a reply I received on my posting)
>
> are there any english words I'm using frequently that are considered
> 'sensitive' by native speakers?? please help me :-)
>
> -------- Original Message --------
> Subject: ScanMail Message: To Sender, sensitive content found and
> action t aken.
> Date: Fri, 26 Jul 2002 05:14:26 -0400
> From: System Attendant <CI...@SUPPLY.GE.com>
> To: "'Steven Noels'" <st...@outerthought.org>
>
> Trend SMEX Content Filter has detected sensitive content.
>
> Place = forrest-dev@xml.apache.org; cocoon-dev@xml.apache.org; ;
> cocoon-dev@xml.apache.org
> Sender = Steven Noels
> Subject = grammar-based pipeline configuration [Re: doctype questions]
> Delivery Time = July 26, 2002 (Friday) 05:14:25
> Policy = Matcher
> Action on this mail = Delete message
I sometimes receive such messages, and never understood what triggers them.
My brain filter detects it as garbage content. Action on this mail =
Delete message also ;-)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: grammar-based pipeline configuration [Re: doctype questions]
Posted by John Morrison <jo...@ntlworld.com>.
I've got that before - a post to infrastructure didn't
resolve it though. Gave up with it.
J.
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
now this is funny... (a reply I received on my posting)
are there any english words I'm using frequently that are considered
'sensitive' by native speakers?? please help me :-)
-------- Original Message --------
Subject: ScanMail Message: To Sender, sensitive content found and action t
aken.
Date: Fri, 26 Jul 2002 05:14:26 -0400
From: System Attendant <CI...@SUPPLY.GE.com>
To: "'Steven Noels'" <st...@outerthought.org>
Trend SMEX Content Filter has detected sensitive content.
Place = forrest-dev@xml.apache.org; cocoon-dev@xml.apache.org; ;
cocoon-dev@xml.apache.org
Sender = Steven Noels
Subject = grammar-based pipeline configuration [Re: doctype questions]
Delivery Time = July 26, 2002 (Friday) 05:14:25
Policy = Matcher
Action on this mail = Delete message
Warning message from administrator:
Content filter has detected a sensitive e-mail.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: grammar-based pipeline configuration [Re: doctype questions]
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
now this is funny... (a reply I received on my posting)
are there any english words I'm using frequently that are considered
'sensitive' by native speakers?? please help me :-)
-------- Original Message --------
Subject: ScanMail Message: To Sender, sensitive content found and action t
aken.
Date: Fri, 26 Jul 2002 05:14:26 -0400
From: System Attendant <CI...@SUPPLY.GE.com>
To: "'Steven Noels'" <st...@outerthought.org>
Trend SMEX Content Filter has detected sensitive content.
Place = forrest-dev@xml.apache.org; cocoon-dev@xml.apache.org; ;
cocoon-dev@xml.apache.org
Sender = Steven Noels
Subject = grammar-based pipeline configuration [Re: doctype questions]
Delivery Time = July 26, 2002 (Friday) 05:14:25
Policy = Matcher
Action on this mail = Delete message
Warning message from administrator:
Content filter has detected a sensitive e-mail.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
RE: grammar-based pipeline configuration [Re: doctype questions]
Posted by Conal Tuohy <co...@paradise.net.nz>.
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> In terms of implementation, this could be a pipeline configuration
> component, a Matcher of Selector. It would require to 'parse' the XML
> document upto a level it can detect its grammar (for DTDs the doctype
> statement, for Schemas the xsi:SchemaLocation attribute, etc),
> sufficiently cached etc...
NB it is possible to do something similar with an XSLT transformation.
I produced a demo of how to select an XSLT transform based on a
processing-instruction in the XML source (I know! This is horrible! But an
xml-stylesheet processing instruction could effectively stand in for the DTD
declaration which is not available once the document is parsed.)
For details, see
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102003720732535&w=2
In terms of the mechanics, you need 2 pipelines: one to produce the
stylesheet appropriate for transforming a given document (i.e. transforms
the source document into a stylesheet suitable for transforming the source
document), and the second pipeline actually applies the resulting
stylesheet.
Your "get-stylesheet.xsl" could detect the doctype by examining the name and
ns of the root element of the document (instead of looking for
processing-instructions as my demo did), and decide on the appropriate
transformation that way.
Cheers
Con
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org