Re: [xsl] character entities

Subject: Re: [xsl] character entities
From: Joerg Pietschmann <joerg.pietschmann@xxxxxx>
Date: Fri, 23 Nov 2001 15:03:09 +0100
David Carlisle <davidc@xxxxxxxxx> wrote:
> [I'm not sure we're still on topic for this list, but anyway..]

Mentioning XSL/XPath a few times should suffice :-)

> > two pass approach.
> Yes but then basically you are in the same situation as with entities:
> You have an expanded document and it isn't necessarily easy to construct
> an unexpanded one from a stylesheet.

First, you can choose whether to expand or not.
Second, you can leave the referencing nodes in the tree and only expand
them by adding the referenced forest as cildren. This will of course
work better if you use diffentiated semantic references where references
cannot occur everywhere whith everything as content, so they are much
easier to integrate in your XPaths. In the case of general references,
you might be able to insert dummy reference nodes, so that every
ancestor::*[position() mod 2=1] of a non-reference element is a
reference element (or whatever else is appropriate).

> > You can use nag:ref-formula, nag:ref-constraint etc.
> I could, but it would still make listing all the arguments used in
> constraints more complicated than the current
> select="//constraints//arg"

I know, therefore i use *always* an indirection:
  <document>
    <constraintdef name="foo-constraint">...</constraintdef>
    <whatever>
      ...
      <constraintref name="foo-constraint"/>
      ...
    </whatever>
  </document>
You obviously can still use select="//constraintdef//args" for global
queries and select="key('constraint',$name)//args" for more local ones.
I admit that editing it will be more of a pain, you'll probably have
to extensively customize your editor at least for fast switching
between references and their definition. An editor which will show
a XSLT transformed result in real time would be a real boon. (I'm
currently wrestling with XMetal...)

> and apart from impressing Jeni...

You'd impress me too, a real achievement :-)

> > If the references become somewhat standardized, you should be able to
> > put this logic into reusable templates.
> It's easier to say "reusable templates" than define what it means.

Ok, i should have omitted the buzzword. I meant that i have templates
for pulling in stuff across references instead of handling everything
inline. These templates could be quite general, i.e. i have some
templates handling a whole bunch of different reference elements.

> Also I'd have to go outside XSLT 1.0 (not
> that that necessarily matters) as if the current template goes
> select="../param/constraints" to select all the constraints on sibling
> parameters, then there is _nothing_ a template can do to create that
> node set, as templates don't create nodesets.

I wonder why Dimitre has not jumped onto this, as that's a prime example
for using generic templates. Write a somewhat general frame for using
recursive templates to collect the nodes you want to have into a node-set
and invoke the desired functionality in the recursive template via the
generic template indirection. (might impress Dimitre too :-)

> It's like saying how do you mix a w3c Schema definition with a relax NG
> one. If you choose to define something in two ways, it's up to you to
> make sure they are compatible. Or more simply just define it one way.

The point was: If you have entities, you'll *have* to use a DTD. If you
actually want to use XSchema (or some other structure definition language),
perhaps because you like XSchema types, you can get dependencies you
don't want to have. A non-validating parser might ignore entity definitions,
a validating one will want to have a structure definition, which duplicates
information from your schema. You may find a parser which expands all
entities without doing validating, but there is no standardized way you
can rely on for using "the best of both worlds".

> that's fine but currently DTD's offer a lot more functionality than
> schemas, so this won't happen soon.

Oops, what functionality beside defining entities for physical
structuring? I'm not sure whether XSchema's has features like
conditional sections, but i think much of the modularisation and
customization of the structure definition could also be achieved with
redefinitions and references to definitions in other namespaces. In
fact, i'd like to have this *now*. My DTD and XSL grew somewhat ugly
*because* DTDs are not namespace aware, and you have only the choice
to define an element as ANY or explicitely state all 100+ allowed
elements instead of allowing a bunch of elements from a namespace.

(Discussing the dependencies between XML structure and the XSL for
processing it would make an interesting thread...)

> There are lots of XML editors out
> there with context sensitive operations driven by dtds. No doubt people
> are working to try to do something similar with schemas, but is it there
> yet?

There was a time without XSLT processors.
Of course Schema driven editors will take a lot more time to appear
and to work even remotely reliable, since schemas are new, much more
complex than DTD and almost impossible to handle without tools. But
poeple will continue to complain about missing the possibility to
define an attribute as a date (so that the editor can open a calendar
widget for input assistance), therefore schema driven editors will
ultimately appear. :-)

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread