Cart
[Home] [By Thread] [By Date] [Recent Entries]
On 7/11/05, bill palmer <palmer@e...> wrote: > >>Given the above, I'd say your heading toward reinventing XSLT (but without > using any of those messy namespaces)...<< > > I am envisioning that this rearrangement of the information depends on XSLT > or equivalemnt. > > In my example of <record>s, and from the stand point of XSLT, I imagine a > template with select="e" which copies each <e/> to a <record/> plus all the > attributes on <g><gx><gi>... > > So I do not see it as a coding method like XSLT, for defining how to > transform arbitrary xml tags to new forms, but it is rather one particular > obvious transform always from <e/> tags. The xml preparer is allowed to defer > the technical implementation of the transform to the recipient of the file. > In my specific example, we might expect the recipient expands to <record>s > before doing validation etc. Umm, I think you missed the point: you don't need any of this, you can already do this (and far more) using XSLT. Eg, you can reference (include) an XSLT from a document, you can add in-line XSLT to a document as a (semi-proprietary) macro format, or add a "document" to an XSLT stylesheet as a variable (or include).... > > If it is a compression idea, then it is a persistent form of compression > residing within the otherwise identical flat xml. The "compressed" file is > the created file in step one, rather than creating a file and then > compressing. > <snip/> -- Peter Hunsberger
|
