Am Don, 2002-02-28 um 16.51 schrieb David Jencks: > Are you saying there is a tool that from grammar transformations will > generate document transformations? > not a tool, a xslt
> g1.xsd transformed to g2.xsd via t1.xsl > there must be a g0.xsd wich contains the rules for g1.xsd and g2.xsd - this way g1.xsd and g2.xsd must be a result of a xslt on g0.xsd g0.xsd is a kind of world-wide-knowledge. we define the edges of our world, it is expandable, it is changable, there is inheritance. > tool generates t2.xsl that will transform > > d1.xml complying with g1 to d2.xsl complying with g2? > > Without this I don't really see the point of your advocacy of xsd here. > Sure it has advantages over dtd's but the hard part is writing the t2.xsl > to transform d1 to d2. It's not even clear that this is harder than > writing t1.xsl to transform the grammars. > for this single iteration, yes - but reality .... my point of advocacy is a little bit abstract, i know: the ability to handle the whole _lifecycle_ of metadata in a standardized manner, far in front of the manufacturing of type desriptors or schemas (IBM issue better manually) today. if the time is comming the metadata should change themself, i.e. change an entity bean in a mdb and create the appropriate model mbean sourcecode while the specification of all three has changed to version j2ee 2.0 or to create an openadapter via introspection of one-to-one java-native mappings. what i mean is a selfcontained description of things we are dealing with. > On 2002.02.28 09:30:58 -0500 Holger Baxmann wrote: > > Am Don, 2002-02-28 um 14.43 schrieb David Jencks: > > > I haven't had any problems using xsl without xsd, and am planning to > > rework > > > the jboss deployment process based on extensive use of xsl > > transformations, > > > so in particular it would be very easy (supply an xsl script) to deploy > > > stuff using your own in -house dd dtd or ???. > > > > > the problem, or more exactly the wall, here is that dtd is not xml, it > > is a sgml construct. but if - and think about - if the contents > > (semantics) documented in an dtd _are_ xml: then you are able to apply > > xslt on your xsd. you provide a set of generic xsd's as a fundamental > > vocabular and if you would use any concrete configuration you apply a > > xslt on the xsd for the specific case [all cases are specific :)] so you > > generate a version-like type of metadata, wellformed and valid xml > > agaist another xml - the xsd. and your are able to generate via xslt a > > standard config out of the definition, the metadata as xsd, of the > > generic config: this means the rawdata are selfcontained because their > > definition is in no way other then themself! one may translate rawdata > > in metadata and vice versa. > > > > you are able to use xpath, xquery, xpointer and all the others on a meta > > level. > > It this really easier than doing it by hand? > > > > as a matter of course, you are able to generate your metadata java > > classes out of your 'dtd' via xslt. it is nice, isn't it? > > Tools? JAXB generates classes including xml parsing. What tool do you > prefer? > > > > ... and last but not least your metadata are validated > > > > not to talk about the much better, and so far more javaish, typing and > > sematic abilities in xsd. > > > > fyi: > > > > DTD -> XSD converter > > http://puvogel.informatik.med.uni-giessen.de/dtd2xs/ > > > > quick XSD: > > > > http://www.xfront.com/xml-schema.html > > > > quick XSL: > > > > http://www.xfront.com/xsl.html > > > > > > > It looks to me as if xsd <--> dtd for schemas > > > > > > and xml <--> xml for documents > > > > > > > in using xsd there is no difference between schemas and documents, > > schemas are documents and documents could be schemas. it is a metter of > > the context. > > > > > What am I missing about xsd? > > > > > > > that xml formulates languages, for example xsd, but xml does not > > formulate dtd on which it rely. > > > > cu > > bax > > thanks > david jencks > <snip> > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
