commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthijs Wensveen <...@wanadoo.nl>
Subject Re: [digester] Rule for processing instruction?
Date Mon, 29 Sep 2003 13:20:37 GMT
robert burrell donkin wrote:

>
> On Friday, September 26, 2003, at 04:08 AM, Craig R. McClanahan wrote:
>
>> robert burrell donkin wrote:
>>
>>> On Thursday, September 25, 2003, at 09:36 PM, Craig R. McClanahan 
>>> wrote:
>>>
>>>> robert burrell donkin wrote:
>>>>
>>>>> hi janek
>>>>>
>>>>> i don't see any reason why we shouldn't put something to allow 
>>>>> access to processing instructions into digester. this probably 
>>>>> means storing the indexed processing instruction (just as your 
>>>>> example code does). probably worth giving a getting for the keys 
>>>>> as well as a per-instruction getter. rules would be able to access 
>>>>> these properties during their execution by calling the properties 
>>>>> on digester.
>>>>>
>>>>> 1. can anyone see any issues with this approach?
>>>>> 2. can anyone think of anything i've forgotten?
>>>>
>>>>
>>>>
>>>> Wouldn't some use cases for processing instructions want to depend 
>>>> on the context in which they occurred?  If so, it might be nice to 
>>>> invent a syntax where you could match on them in rules, just like 
>>>> we match on element names.
>>>
>>>
>>>
>>> yes, i think you might be right. i can think of three distinct use 
>>> cases:
>>>
>>> the first is where a standard (?element?) rule needs to know what 
>>> processing instructions have been encountered before it's called. 
>>> this would cater for the usage where context insensitive processing 
>>> instructions are given at the top of the file before the elements. 
>>> (this usage case is what i was thinking about before.)
>>>
>>> the second is when a processing instruction is encountered, an 
>>> action (rule) is fired and the rule or rules which are fired depends 
>>> on the element path. this could probably be done by adding an 
>>> optional processing instruction callback to Rule
>>>
>>> the third is allowing matching on processing instructions as well as 
>>> element names. IMHO this would need a bit of thinking about. for 
>>> example,
>>>
>>> <alpha>
>>>     <? org.apache.commons.digester.COLOUR RED ?>
>>>     <beta>
>>>         <epsilon>
>>>             <? org.apache.commons.digester.COLOUR GREEN ?>
>>>             <beta>..</beta>
>>>         </epsilon>
>>>     </beta>
>>>     <? org.apache.commons.digester.COLOUR BLUE ?>
>>>     <beta>...</beta>
>>>     <gamma>...</gamma>
>>> </alpha>
>>>
>>> would only children of epsilon be able to match on 
>>> org.apache.commons.digester.COLOUR GREEN? would they want to match 
>>> on multiple instructions?
>>>
>>> in terms of implementations, i think that maybe matching on 
>>> processing instructions might be orthogonal to the more usual 
>>> element matching. maybe it'd be better to have a string for each 
>>> (rather than a combined syntax).
>>
>>
>> <? thinking.out.loud ?>
>>
>> Sorry ... couldn't resist :-).
>>
>> IIRC, a "?" is not legal in the name of an XML element, right?  
>> Therefore,
>>  we could do something simple like say that a leading "?" in a 
>> pattern element would match a PI instead of an element, so we could 
>> just fire all the usual rules when matching 
>> "alpha/?org.apache.commons.digester.COLOUR"
>>  or "alpha/beta/org.apache.commons.digester.COLOUR" or even 
>> "*/org.apache.
>> commons.digester.COLOUR" to catch them both.
>
>
> sounds good so far :)
>
> we'd probably need to have an ignorePIs flag that would start out true 
> to avoid breaking existing patterns.
>
>> We'd have to simulate the data value as an Attributes structure, and 
>> a couple of other wrinkles like that, but I bet this would cover a 
>> substantial number of use cases.
>
>
> why not just add a processingInstruction method to Rule?
>
> here's my hypothetical example of a computer that is linked to a 
> (robotic)
>  tea machine which can create a warm beverage whilst processing a 
> particularly long xml document. for example:
>
> ...
> <alpha>
>     <? org.apache.commons.digester.tea WARM POT ?>
>     <beta>...</beta>
>     <? org.apache.commons.digester.tea BOIL WATER ?>
>     <gamma>...</gamma>
>     <? org.apache.commons.digester.tea INFUSE ?>
>     <delta>...</delta>
>     <? org.apache.commons.digester.tea SERVE ?>
> </alpha>
> ...
>
> the RoboticLinkRule would be mapped under <alpha> and then whenever it 
> recieves a org.apache.commons.digester.tea PI it would send the 
> correct signal through the firewire connection to the tea producing 
> robot. (this is a use case that i can really relate to ;)
>
> - robert


http://www.w3.org/TR/REC-xml#sec-pi says:
"PIs are not part of the document's character data 
<http://www.w3.org/TR/REC-xml#dt-chardata>, but must be passed through 
to the application."
To me this means that you shouldn't catch PI's but send them directly to 
'the application'. So PI's aren't context sensitive?
I don't really understand what you can do with processing instructions 
that you can't do with 'normal' xml. Sending instructions to the tea 
machine can be done by subclassing Digester and overriding the 
processingInstruction method. Or by adding a CallMethod rule if the 
instruction is context sensitive.

However, I can imagine that you would want a PI to work on a particular 
rule/pattern in some scenarios where normal xml elements are 
semantically inappropriate. So I agree with Robert's suggestion of 
adding a processingInstruction method to Rule. Digester's default 
behaviour would be to send PIs to the appropriate Rule. Users wanting 
more direct access to PIs could subclass Digester and override the 
processingInstruction method, do their stuff with the PI and call 
super.processingInstruction(..) (if they want to).

Yours humbly,
Matthijs.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message