[
Lists Home |
Date Index |
Thread Index
]
-----Original Message-----
From: Paul Spencer [mailto:paul@alphaxml.com]
Sent: Mon 6/17/2002 7:01 AM
To: Xml-Dev
Cc: Roger L. Costello
Subject: [xml-dev] Best Practice - beyond schema
>There are two reasons for needing to go beyond XML Schema on a project
>that is using XML Schema as its base constraint syntax.
>The other situation, and the one that is a more immediate concern, is
>the situation where we need to localise a general purpose schema.
The term localize is overloaded here. At MS when we say localize, we mean converting the application/document to the local language. Is this what you mean or something else?
>For example, some
>audit information is required in a UK parliamentary election but
>forbidden in a US gubernatorial or presidential election. It is
>optional in the schema, but mandatory for the UK and forbidden in the
>USA.
OK, I see. This actually is probably one of the few areas where I can state without reservation that W3C XML Schema provides benefits over any of the other XML schema languages I have seen. However, this is actually an important consideration in many real world scenarios.
>This requirement for profiling schemas is common, but not one I
>have seen addressed in open discussion.
I've seen this topic discussed from different angles on XMLSCHEMA-DEV and there as some tips in the XML Schema: Best Practices Homepage[0]
>Here are two ways of approaching it:
>Write new, more restrictive, schemas for each regime such that a
>document that validates to the local schemas will validate to the
>global schema (but not necessarily vice versa).
When you say write a new schema, do you mean use type derivation, imports, inclusion, redefinition, etc to base a local schema from the global one or actually physically rewriting a different schema taking care that both schemas can validate the same data? The former approach uses W3C XML Schema in a way that it was designed to be used while the latter is a gross hack of the worst kind.
>This has the advantage that only a single schema processor is required, and it will be an XML
> Schema processor
W3C XML Schema can allow open content models using wildcards (xs:any & xs:anyAttribute) which in fact is better than open content models because you can control the occurence of these new items to some degree, whether they have to be schema valid and what namespace they come from.
>Even using derivation, there will be a lot of work developing and
>checking any new version of the local variant when a new global
>version is released.
The problem of versioning local variants of global schemas is one that you will face regardless of what schema language you use. Your alternatives to this are a.) using a single global schema which is updated centrally and distributed to all parties on version changes or b.) versioning at the schema level by using versioned namespace URIs such as "urn:xmlns:25hoursaday:06:2002:ElectionSchema" which is a clear unambigouos way to seperate versions of instance and schema documents.
>Use an open (open in terms of allowing any content that is not
>expressly forbidden) schema language to supplement the closed XML
>Schema schema.
As I mentioned above open content models can be expressed in XML Schema using wildcards. What specific needs do you have that cannot be handled much better by wildcards instead of using two schema languages?
PS: I wrote an article about this topic for XML.com which I assume should be out soon. I will forward a link to this thread once it shows up.
[0] http://www.xfront.com/BestPracticesHomepage.html
|
