OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] dynamically generated XML Schema?! Re: [xml-dev] R: [xml-d

[ 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>
>
>



-- 


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS