[
Lists Home |
Date Index |
Thread Index
]
Burak Emir <burak.emir@epfl.ch> asks:
> Chizzolini Stefano wrote:
>
> >
> >I think there are some valid reasons for writing schemas in XML:
> >seamlessness, elegance and power. Adopting a "self-describing" language
> >syntax avoids the users from learning a new one and allows to leverage many
> >existing applications derived from the original spec (in this case, XML
> >spec); I mean, for example, the chance to dynamically generate brand new
> >schemas through XSL transformations.
> >
> >
> One can of course endlessly discuss about syntax, but I have never
> understood the obsessiveness of marking up descriptions of XML data in XML.
>
> Who needs to dynamically generate schemas?
Umm, we do.
> The whole point of schemas is
> to be a widespread, well understood description of instances.
In our cases we have a lot of metadata described in a relational
database. There are customizations of that metdata that select
specific pieces based on the authorizations of the user and the usage
context of the meta data. The only time we need a schema is for the
description of a piece of instance data that is travelling beyond the
boundaries of the system, so we generate the schema as we need it.
This may sound like a problem of not having a powerful enough schema
language and in a way it is. However, my general philosophy is that I
will generate no schema before it's time...
>
> If you generate a shining brandnew schema dynamically using X, you end
> up with a description that did not exist before. Ergo, the risk is that
> you do not have conforming documents.
>
In our case we generate the schema before we generate the instance
data for which it is used (I hesitate to call it a document, but
that's another issue).
> Now one can dwell in discussion of hypothetical families of schemas, but
> for all my experience tells me about modelling, if you manage to
> understand what the common things are that make a bunch of schemas a
> family, then you can anticipate the extensibility you need, which
> removes completely the need for dynamic generation.
Yes and no. We have a meta-schema. It's so abstract and so
generalized that it's difficult to use for specific instance data.
The problem is, understanding of the schema is often local to the
schema writer. Not everyone "gets" 5th normal form, 5th normal form
doesn't work when the data hit's the data warehouse.
> What is a use case for dynamically generated schemas?
For one, you need different schema for different stages in the life of
the data. I know of no technology that lets you adequately describe
all possible transformations of the schema over time from within the
schema itself. As a specific example (discussed previously on the
list), you need a way to match versions of the schema to work flow.
> Why does one need to use XSL for it ?
You don't, but in our case, we've got about 8 different pieces of
source metadata that have to be combined and transformed in order to
derive a specific schema. XSL is the best match to the problem I know
of.
> Why couldn't one use non-XML syntax for it?
Sure, but I'd still want to use XSL to create it. But that takes us
back to the real issue: do you need name spaces for any of what I just
described? I'm not sure....
--
Peter Hunsberger
(switching e-mail providers, thanks Uday)
|
