[
Lists Home |
Date Index |
Thread Index
]
Hi Tan.
Your questions were interesting and made me realize ways in which I was
not clear in my initial statements.
>> 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 interpret this to mean that you have normalized your XSLT codes
> and you permute it via another XSLT according to some local context.
> Right ?
Yes this is correct for each case we deal with, where normalized XML is
translated to localized XML by use of an XSL transform. The case where we
translate the interface widget contents is a special case in which the
starting and ending documents are XSL.
> Assuming my interpretation is correct, pardon me if I'm wrong, then,
> I can understand this approach. The input is deterministic and you
> can interpret part of its content to extract the context to determine
> the permutation path to take to realize that localization.
Actually the (XML) input doesn't always contain information about the
target locale, often the processing engine (sometimes the web application,
sometimes custom configuration in the CMS) determines the locale and that
determines how the transform is used to translate to the appropriate
language values.
Other times we want to pre-generate all the localized versions, so we run
through the transform for every locale for which localized values are
available and store the results as a set of documents.
> 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 ?
As I say we have not yet gone down this path but primarily I could see
localizing schemas when attribute values or enumerations are specified, as
we've always gone down the path of localizing document contents not XML
tag or attribute names.
In that case, we'd want a different valid set of values for a given field
when validating (for example) a German instance than when validating a
French instance. In this case generating schemas would seem to have some
possible point of traction. I may have implied a more general or complex
case and I'm not sure how that would play out in reality.
------------->Nathan
>
> 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
> conditional validation)
>
>>
>> ---------->Nathan
>>
>> On Thu, 4 Nov 2004 09:55:55 -0000, Michael Kay
>> <michael.h.kay@ntlworld.com> 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.
> A
>> > 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>
>>
>>
>>
>
>
> -----------------------------------------------------------------
> 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>
>
>
--
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
|
