Reducing the number of parsers

(Oops. Sorry for misposting this to mt-notices.)

Well, maybe not quite reducing them, but I've been thinking
of replacing 
(as a first step) the TPLparser in the translations module
with 
something based on SimpleXML or XMLReader in view of where
we're going 
with BL2. However, either the documentation is spotty or I'm
missing 
something, because I'm having trouble either having the
parsers ignore 
the xar entities in template markup or getting them to
recognize them.

Has anyone had more experience in this area and/or some
advice to offer?

Thanks,
Marc
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

On 9 apr 2008, at 23:02, marcinmilanxaraya.com wrote:

> Well, maybe not quite reducing them, but I've been
thinking of  
> replacing
> (as a first step) the TPLparser in the translations
module with
> something based on SimpleXML or XMLReader in view of
where we're going
> with BL2. However, either the documentation is spotty
or I'm missing
> something, because I'm having trouble either having the
parsers ignore
> the xar entities in template markup or getting them to
recognize them.
>
> Has anyone had more experience in this area and/or some
advice to  
> offer?
>

Recognising them will be a pain since we use an 'open ended
set' of  
entities and we can not define them all (although there is a
dummy DTD  
on xar.com which can be referenced which lists quite a few
of them).

Ignoring them will be impossible, but i suspect you mean
'doing  
nothing with them'. If there is an entity in an XML file a
parser will  
need the information what it means, otherwise it will error
out.  
Nothing to be done about that.

Obviously we have this problem in every area where we deal
with XML.  
Strategies i have been using so far:
1. preprocess: make sure internally the entities are
pre-processed  
before the xml stream hits the parser; (easy)
2. fool: fool the parser into thinking the entity is
defined, by  
referring to a DTD which defines the entity. (this
refererall may be a  
php script delivering a dynamic DTD with just the entities
in that xml  
file for example.
3. avoid: in some cases, replacing the entity in the source
file with  
an alternative is just the easiest route and then pretend
there is no  
underlying problem 

Hope this helps.

btw, given the changes we plan in MLS, is this worth the
trouble at  
this time? There are quite a few unknowns to clear up wrt
MLS,  
including the format of BL templates, which means the parser
would  
need to change anyway when we know how to encode the
templates  
properly for ML constructs.

marcel

-- 
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV   -- http://www.hsdev.com
So! webapplicaties  -- http://make-it-so.info



_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

Marcel van der Boom wrote:
> On 9 apr 2008, at 23:02, marcinmilanxaraya.com wrote:
> 
>> Well, maybe not quite reducing them, but I've been
thinking of replacing
>> (as a first step) the TPLparser in the translations
module with
>> something based on SimpleXML or XMLReader in view
of where we're going
>> with BL2. However, either the documentation is
spotty or I'm missing
>> something, because I'm having trouble either having
the parsers ignore
>> the xar entities in template markup or getting them
to recognize them.
>>
>> Has anyone had more experience in this area and/or
some advice to offer?
>>
> 
> Recognising them will be a pain since we use an 'open
ended set' of 
> entities and we can not define them all (although there
is a dummy DTD 
> on xar.com which can be referenced which lists quite a
few of them).
> 
> Ignoring them will be impossible, but i suspect you
mean 'doing nothing 
> with them'. If there is an entity in an XML file a
parser will need the 
> information what it means, otherwise it will error out.
Nothing to be 
> done about that.
> 
> Obviously we have this problem in every area where we
deal with XML. 
> Strategies i have been using so far:
> 1. preprocess: make sure internally the entities are
pre-processed 
> before the xml stream hits the parser; (easy)
> 2. fool: fool the parser into thinking the entity is
defined, by 
> referring to a DTD which defines the entity. (this
refererall may be a 
> php script delivering a dynamic DTD with just the
entities in that xml 
> file for example.
> 3. avoid: in some cases, replacing the entity in the
source file with an 
> alternative is just the easiest route and then pretend
there is no 
> underlying problem 
> 
> Hope this helps.

Thanks, it does. I was just trolling for reasonable
alternatives. Guess 
for the problem at hand I'll go with preprocessing.
> 
> btw, given the changes we plan in MLS, is this worth
the trouble at this 
> time? There are quite a few unknowns to clear up wrt
MLS, including the 
> format of BL templates, which means the parser would
need to change 
> anyway when we know how to encode the templates
properly for ML constructs.
> 
that is true. I'm just looking at the translations module
and thought 
that the engine of that parser could be replaced by probably
less than 
20 lines of code (hats off to Marco tho). this little
exercise will 
likely never see the light of day, but it lets me run
translations 
module in the transitionmls scenario.
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

Marcel van der Boom wrote:

> On 9 apr 2008, at 23:02, marcinmilanxaraya.com wrote:
> 

> 
> Recognising them will be a pain since we use an 'open
ended set' of  
> entities and we can not define them all (although there
is a dummy DTD  
> on xar.com which can be referenced which lists quite a
few of them).
> 

I vote we drop support for entities that get parsed at
runtime: url, 
modurl, mod, and var.

We should then add more entities for data that always exists
but whose 
values change, such as:

- module url arg &xar-url-module;
- type url arg &xar-url-type; *
- func url arg &xar-url-func;
- current theme name &xar-theme-name; **
- current theme directory &xar-theme-dir; **
- current theme basepath &xar-theme-path; **
- uid &xar-uid;
- uname &xar-uname;

Essentially, let's move to a closed, robust, known set of
entities. 
Wouldn't this solve a lot of parser and DTD/schema issues?

* Irrelevant in 2x, but could be maintained as a flag to
control overall 
user/admin interface (ie, dashboard).

** Resolved based on file location, not system setting. 
Default 
templates would resolve to the default theme.
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

marcinmilanxaraya.com wrote:

> that is true. I'm just looking at the translations
module and thought 
> that the engine of that parser could be replaced by
probably less than 
> 20 lines of code (hats off to Marco tho). this little
exercise will 
> likely never see the light of day, but it lets me run
translations 
> module in the transitionmls scenario.

It's also a lazy man's way of checking for XML consistency
in the 
templates 
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

On 11 apr 2008, at 24:03, Marty Vance wrote:

> Essentially, let's move to a closed, robust, known set
of entities.
> Wouldn't this solve a lot of parser and DTD/schema
issues?

It would help a little, by reducing the size of the set of
possible  
entities. We still would need to preprocess templates for
entity  
resolvement as xml views entities as constants. I think we
can cope  
until we have more places in xaraya where we transition from
'somewhat  
xml-like' to 'actual xml' Along the way we will encounter a
number of  
challenges which will perhaps reduce the problem with the
variable set  
of entities. (like XPath addressable data)

-- 
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV   -- http://www.hsdev.com
So! webapplicaties  -- http://make-it-so.info



_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel