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 ]

> -----Original Message-----
> From: Burak Emir [mailto:Burak.Emir@epfl.ch] 
> Sent: Thursday, November 04, 2004 04:29
> To: Alessandro Triglia
> Cc: XML Developers List
> Subject: Re: [xml-dev] dynamically generated XML Schema?! Re: 
> [xml-dev] R: [xml-dev] Number of active public XML schemas
> Alessandro,
> Alessandro Triglia wrote:
> >Another case of dynamic generation is translation between 
> schema languages.
> >
> >  
> >
> I don't see how this brings me closer to a use case for dynamic 
> generation, in the sense that some event happens, a schema has to be 
> generated, and we can use this schema to validate data.
> I see that when you have such a use case (i.e. one like Jeff Reif 
> suggested), this can imply one needs schema translation, but not the 
> other way round.
> >An example is the X.694 standard, which specifies a 
> translation from XML
> >Schema to ASN.1.  There has been a proposal to standardize 
> the reverse
> >translation as well.
> >
> >However, in the case of X.694, the fact that the source 
> syntax is XML does
> >not play a significant role.  X.694 converts abstract 
> **schema components**
> >to equivalent ASN.1 constructs, so it doesn't really deal 
> with the XML
> >representation of XSD.  (Before applying X.694, schema 
> documents must be
> >converted to abstract Schemas as specified in the XML Schema
> >Recommendation.)
> >
> >  
> >
> I did not find the word "abstract schema" in the Rec, I guess 
> you mean 
> "its meaning".

No, I don't mean "its meaning".

XSD specifies two distinct things: an abstract data model and an "XML representation".  A "Schema" (as used in the Rec) is not an XML document.  It is a collection of abstract "schema components", such as element declarations, simple/complex type definitions, attribute declarations, etc.

Validity assessment is specified in terms of those abstract schema components, not in terms of <complexType> elements and the like.  The Rec says that the abstract schema components may be represented in XML but don't have to.  

In a sense, XSD is a language with no inherent syntax (or with a pluggable syntax if you wish).  The "XML representation" is one possible syntax, but the Rec does not mandate its use.  The Rec explicitly allows the use of other syntaxes or other (non-syntactical) means to build a representation of the schema components in memory.

See the conformance clause (2.4) of the Rec.  Conformance has three levels, and you can be conformant ("minimally conformant") without implementing the XML representation at all.

The following Note in the conformance clause is interesting:

Note: By separating the conformance requirements relating to the concrete syntax of XML schema documents, this specification admits processors which use schemas stored in optimized binary representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code such as C or Java. Such processors can be said to be ˇminimally conformingˇ but not necessarily in ˇconformance to the XML Representation of Schemasˇ.

But the whole clause 2 "Conceptual Framework" is interesting as well.


The X.694 standard took the approach of mapping from the abstract Schema of XSD to the target language (ASN.1).  The prior mapping from the schema documents to the Schema is handled by the XSD Rec, and does not need to be re-specified in another standard.



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

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