[
Lists Home |
Date Index |
Thread Index
]
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".
I fully agree that as long as the meaning is clear, any representation
(and any language to translate the schema) will do.
>***
>
>In general, I think that the use of XML for a new formal language designed
>primarily for human consumption may or may not be a good choice. There are
>pros and cons to it.
>
>Using XML can facilitate the creation/specification of a new language, the
>development of early tools for the new language, and the learning of the new
>language. On the other hand, an adequate non-XML syntax can make the
>language more usable by those who have learned it.
>
>
>
[This has little to do with "dynamical generation", but...]
This is true. In some sense, most formal languages introduce some
algebra of operators, XML merely disallows abuse of notation and being
drowned in syntactic convention.
But then, XML also adds its own syntactic twists (hello, namespaces,
especially in attribute values inside XML Schema definitions).
>Recently, I developed a specification of an ad-hoc language for conformance
>testing, and decided to use an XML syntax for it. I felt this was very
>appropriate in that case, because it makes the language simpler. It took me
>less time to write the specification, and it will take less time to whomever
>will implement it. The instances of use of the language (conformance
>assertions) will be rather verbose, but since it is a niche language, the
>total number of hours that people will spend using the language (reading and
>writing) will be very low.
>
>I think the arguments "pro" an XML syntax, in a formal language designed
>primarily for **human consumption**, become weaker if the language is
>expected to be widely used.
>
>
>
That does not preclude having an XML syntax *and* a more concise non-XML
syntax, a la Relax.
Probably nobody on this list can disagree that in general, using XML
makes sense :-)
But sometimes it means a considerable step back (like this namespace in
attribute values issue). The syntax should not be relevant for the
meaning, yet we end up with namespace prefixes needing to be preserved
when parsing an XML Schema with a normal parser.
cheers,
Burak Emir
http://lamp.epfl.ch/~buraq
|
