[
Lists Home |
Date Index |
Thread Index
]
What problem does this solve?
On 7/11/05, bill palmer <palmer@execpc.com> 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.
>
> 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.
>
> As for namespaces I think we would need to use something like <GE:e> and
> <GE:g> tags in practice.
>
> regards,
>
> bill p
>
>
>
> Peter Hunsberger wrote:
>
> > On 7/8/05, bill palmer <palmer@execpc.com> wrote:
> > > Sorry if this is an old idea. The more I have experimented with the idea
> > > recently, the more compelling it seems.
> > >
> > > What if repetitive fragments of xml had default non-flat format? Perhaps
> > > a "standard" non-flat syntax would be always recognized and flattened in
> > > a manner understood by all processors.
> >
> > Depending on which direction you want to take this idea you've either
> > reinvented basic compression or XSLT.
> >
> > >
> > > Essentially a block of flat records would be entered as <e/> leaf nodes
> > > of nested <g/> outer elements. All attributes on the <g/> elements would
> > > be repeated on the <e/> elements.
> > >
> >
> > <snip type="explanation of the above"/>
> >
> > Given the above, I'd say your heading toward reinventing XSLT (but
> > without using any of those messy namespaces)...
> >
> > --
> > Peter Hunsberger
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
<M:D/>
M. David Peterson
http://www.xsltblog.com
|
