Lists Home |
Date Index |
> We've used this transform on several layers. We've applied transforms to
> the data XML to come up with translated instances (translating content not
> tags). We have translated the XSL to localize interface widget contents.
> We've translated XHTML output before sending it to the browser. We use
> the same set of tags to indicate translatable content at each of these
> layers and the same transform as well.
I interprete this to mean that you have normalized your XSLT codes
and you permute it via another XSLT according to some local context.
Assuming my interpretation is correct, pardon me if I'm wrong, then,
I can understand this approach. The input is deterministic and you
can interprete part of its content to extract the context to determine
the permutation path to take to realize that localization.
(I am discounting context that are derived externally, say your URL,
cgi, cookies variables; this is irrelevant because your input is still
deterministic for transform)
However, I am still pondering over how this would work using dynamic
schemas as we must somehow get some context from our input.
If our input can be 1 of N possibilities (as an example, depending
on some workflow state), then how can we efficiently extract the
context to generate the correct schema for validation when the
input has not been determined ?
I can think of a few tricks but they are not general.
> Our markup for translatable elements could be put into schemas as well.
As an XML store ? For purpose of our discussion, how does your
translatable elements look like. Do you have a url where I can
have a look at this ?
> Although we have not yet localized any of our schemas, I think we will be
> taking that path within the next 6 months. Perhaps this is a good use
> case for dynamically generated schema.
It will be interesting to know your findings.
> We haven't approached solving this, and in fact I just thought of it as I
> read this thread, so if anyone has identified better solutions for
> localizing schemas, let me know.
Its obvious to me that somehow we need to know the context without
the privilege of a validated input as a first step. (external context aside
because that would mean at least 2 data paths and xsd cannot do
> On Thu, 4 Nov 2004 09:55:55 -0000, Michael Kay
> <firstname.lastname@example.org> wrote:
> >> Shouldn't it be the case that the validation process necessitates
> >> a 2-stage parsing ? What I mean is that XSD can only do a lexical
> >> validation, a second follow-up stage that validates against the
> >> application semantics is required.
> > That's actually four levels already: unicode encoding, XML
> > well-formedness,
> > schema validity, and application validity. And yes, you often need
> > multiple
> > levels.
> > But that doesn't stop you wanting individual levels to be configurable.
> > very simple example, when I validate new documents I want to check that
> > the
> > date is today. That kind of thing is very easily achieved by a
> > configurable
> > schema. Equally, the application-level validation is often done using
> > XSLT
> > stylesheets, and people often transform stylesheets for the same reason:
> > you
> > need things to be configurable at that level too.
> > Michael Kay
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>