Parse rules as data
[1/7] from: brett:codeconscious at: 27-Jun-2001 18:16
Just musing..
If a set of parse rules validate some data, then they certainly describe it
too.
I was wondering that if given data-A that is parsed by parse-rules-A
and parse-rules-B a smart program could produce data-B that can be parsed
by parse-rules-B. As in:
Data-B: TRANSFORM data-A parse-rules-A parse-rules-B
Probably would need transform-hints-from-A-to-B as well I suppose, in some
form.
Even a constrained (in terms of rules) solution might be handy.
I suppose this steps into the same space as XSLT and tree-rewriting.
Just whip me up one please.. Thanks.. :)
Brett.
[2/7] from: joel:neely:fedex at: 27-Jun-2001 3:13
Hi, Brett,
Handy idea for creating test data...
Brett Handley wrote:
> Just musing..
> If a set of parse rules validate some data, then they
<<quoted lines omitted: 4>>
> Probably would need transform-hints-from-A-to-B as well
> I suppose, in some form.
Many years ago in a galaxy far, far away, I wrote a data
generator that took "specs" that were essentially a simple
form of regular expressions and created output that matched
those specs.
There are a couple of policy questions:
1) How much data does one want?
2) How specific should one be about "holes" in the data?
With regard to (1), given
digit: charset [#"0" - #"9"]
lcalpha: charset [#"a" - #"z"]
twochar: [digit lcalpha]
there are 260 possible distinct strings that match TWOCHAR
(assuming case sensitivity). Should the generator create
all of them, or be told how many to create at random, and
with/without duplicates allowed?
Given
label: [lcalpha some [digit | lcalpha]]
the length of a *single* LABEL becomes an open issue.
With regard to (2), given
attrval: [label {="} copy val to {"} skip]
there's a severe lack of hints about what characters might
appear between the quotes. There could be multiple such
holes
in a set of parse rules.
What would be a good way to supply those hints?
1) Making the parse rules more specific?
2) Refinements on the DEPARSE function?
3) Special comments within the parse rules?
4) ...any other thoughts?
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[3/7] from: brett::codeconscious::com at: 28-Jun-2001 1:05
Hi Joel,
Thanks for your reply.
The idea you think I had appears not to be the one I think I had. But you're
most welcome to pursue the former, though my interest is actually in the
latter.
The latter being as follows in example form:
author-index: context [
author-entry: [author author-rebsite]
author: [string!]
author-rebsite: [url!]
model*: [ any author-entry ]
content*: [
"Brett Handley" http://www.codeconscious.com/index.r
"Joel Neely" http://www.textimage.com/REBOL/index.r
"Allen Kamp" http://www.rebolforces.com/index.r
]
]
So I can do:
>> parse author-index/content* author-index/model*
== true
Then I'd like to provide a new model and have content "calculated" for me
doing something like:
rebsite: transform author-index rebsites-spec hints-spec
where rebsites-spec is
rebsite-spec: context [
reblink: ['folder linkurl 'info author]
author: [string!]
linkurl: [url!]
model*: [ any reblink ]
]
and hint-spec contains the magical transformation dialect that makes it all
possible :)
author-entry -> reblink
author -> author
author-rebsite -> linkurl
So for example I might end up with something like this:
rebsites: context [
reblink: ['folder linkurl 'info author]
author: [string!]
linkurl: [url!]
model*: [ any reblink ]
content*: [
folder http://www.codeconscious.com/index.r info "Brett Handley"
folder http://www.textimage.com/REBOL/index.r info "Joel Neely"
folder http://www.rebolforces.com/index.r info "Allen Kamp"
]
]
and again I can do:
>> parse rebsites/content* rebsites/model*
== true
So I guess I'm wondering if some function 'transform and some fantastic
transformation dialect will be more economical than just writing the
transformation directly in straight Rebol code.
Should I go back to dreaming?
Maybe the data generator will be more useful :)
Brett.
[4/7] from: joel:neely:fedex at: 27-Jun-2001 10:24
Hi, Brett,
Brett Handley wrote:
> The idea you think I had appears not to be the one I think
> I had. But you're most welcome to pursue the former, though
> my interest is actually in the latter.
>
You're welcome to credit for both! ;-) I was just observing
another application of the root notion of "reverse interpreting"
the parse dialect.
> Then I'd like to provide a new model and have content
> "calculated" for me doing something like:
<<quoted lines omitted: 8>>
> and hint-spec contains the magical transformation dialect
> that makes it all possible :)
...
> So I guess I'm wondering if some function 'transform and some
> fantastic transformation dialect will be more economical than
> just writing the transformation directly in straight Rebol code.
>
I'd guess it depends on how often one does transformations that
are sufficiently similar. There are probably situations where the
(possibly high) investment in effort to implement the transformer
would have a payback over repeatedly hand-crafting the individual
translations, but I'd need LOTS of experience doing the specific
cases before I'd feel comfortable doing the general case.
> Should I go back to dreaming?
>
Dreams are good! For some dream-inspiration, take a look at
the specs for XSL and XSLT at
http://www.w3.org/Style/XSL/
They're addressing the corresponsing problem for XML -- given one
structure expressed in XML, how can one write rules that specifiy
how to map it to a different structure in XML/HTML/XHTML?
It might give you some more ideas.
--
It's turtles all the way down!
joel'dot'neely'at'fedex'dot'com
[5/7] from: jseq:mediaone at: 27-Jun-2001 9:18
Brett,
Isn't it quite possible that the two sets of rules are completely orthogonal?
For example, Carl's parse samples include driving directions and a cooking recipe.
How would you automatically transform between the two?
I think that once you'd added the rules or hints needed to effect the transform, you'd
have a nice little rebol script and very little logic left for the common
engine to implement.
JS
EIS Architect
http://www.pobox.com/~johnseq
6/27/01 4:16:03 AM, "Brett Handley" <[brett--codeconscious--com]> wrote:
[6/7] from: brett:codeconscious at: 28-Jun-2001 19:50
Hi John,
> Isn't it quite possible that the two sets of rules are completely
orthogonal?
> For example, Carl's parse samples include driving directions and a
cooking recipe. How would you automatically transform between the two?
No doubt that there could be orthogonal sets of rules, and in such cases it
may be a nonsense to try to transform between them. Though given the
activity around e-commerce languages and XSLT type transformations there is
probably a family of transforms that would be useful to do. I suppose it
would have to be up to the user to decide whether to initate the tranform or
not.
> I think that once you'd added the rules or hints needed to effect the
transform, you'd have a nice little rebol script and very little logic left
for the common
> engine to implement.
That was bothering me also, but I thought I'd send up the kite to see if it
would fly. I thought there should be something smart that one could do with
meta-data + meta-data.
I suppose it is equivalent to having a relational database with schema-a and
asking it to export and then load into schema-b.
Tricky :)
Brett.
[7/7] from: jseq:mediaone at: 28-Jun-2001 11:38
Brett,
As you mentioned below - the metadata is key (which goes beyond simple parse rules).
The RDF crowd is trying to do exactly the schema-a to schema-b tranform you describe.
Apple created something well regarded in this area with their Meta Content Framework
and Hot Sauce project. I believe the effort is either dead or rolled into current
W3C RDF projects.
http://www.w3.org/TR/NOTE-MCF-XML/
http://home.netscape.com/columns/techvision/innovators_rg.html
Carl has suggested REBOL playing a role similar to XML/RDF and metadata. I'm looking
forward to the rebol approach to these thorny interoperability issues.
JS
http://www.pobox.com/~johnseq
6/28/01 5:50:15 AM, "Brett Handley" <[brett--codeconscious--com]> wrote:
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted