[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Idea - std. non-flat <g><e/></g> syntax

• To: "M. David Peterson" <m.david.x2x2x@g...>
• Subject: Re: Idea - std. non-flat <g><e/></g> syntax
• From: bill palmer <palmer@e...>
• Date: Tue, 12 Jul 2005 19:29:17 -0500
• Cc: Peter Hunsberger <peter.hunsberger@g...>,"xml-dev@l..." <xml-dev@l...>
• References: <42CF2B25.88A668F4@e...> <cc159a4a05071020321c5ba644@m...> <42D21566.22401AAC@e...> <f8da4eba05071101236c624f80@m...>

>>What problem does this solve?<<

The problem is that  flat xml data is not as readable as a hierarchical rendering
that writes the boiler plate attributes and child elements only once. I accept that
these forms of flat xml have geat utility to those who deploy them, but I maintain
it is also desirable to have a standard way to use the "inherent" hierarchical
arrangement.  So this is the problem ... that we do not have a standard way.  By
"standard" I mean a built-in process, so that others automatically know what I
expect them to do with it....i.e. in my examples:  find <e.>s -> interpret as
<record>s.

I would like the choice to use hierarchy at the same level as whether to use
apostophes or quotes on attributes.  But where that choice is a trade-off, a
"standard" hierarchy gives a compression benefit over the flat-only xml. So that is
at least helpful in the problem of  naturally bloated xml files.

In many cases this would also make xml markup more  friendly and visually verifiable
for non-technical users. Many files that I have reformatted to test this seem not to
even need any reporting application since everything looks great with nothing more
than indention and syntax highlighting. So I guess that is the problem of having to
wriite special reports.

regards,

bill p

"M. David Peterson" wrote:

>
>
> 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.
> >
> >   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@e...> 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

• References:
  • Idea - std. non-flat <g><e/></g> syntax
    • From: bill palmer <palmer@e...>
  • Re: Idea - std. non-flat <g><e/></g> syntax
    • From: Peter Hunsberger <peter.hunsberger@g...>
  • Re: Idea - std. non-flat <g><e/></g> syntax
    • From: bill palmer <palmer@e...>
  • Re: Idea - std. non-flat <g><e/></g> syntax
    • From: "M. David Peterson" <m.david.x2x2x@g...>

• Prev by Date: Re: Idea - std. non-flat <g><e/></g> syntax
• Next by Date: Re: Idea - std. non-flat <g><e/></g> syntax
• Previous by thread: Re: Idea - std. non-flat <g><e/></g> syntax
• Next by thread: Re: Idea - std. non-flat <g><e/></g> syntax
• Index(es):
  • Date
  • Thread