[exprla-devel] RE: [xpl] Groves Annotated
Status: Pre-Alpha
Brought to you by:
xpl2
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:13:24
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Thanks a lot Jonathan; this helps immensely. Some comments inline
follow....
-----Original Message-----
From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
Sent: June 19, 2000 9:29 PM
To: xpl@e...
Subject: Re: [xpl] Groves Annotated
Richard Anthony Hein wrote:
Great input Jonathan, once again. I wish I understood more than
half
of what you said.
Half's a start. The gist of it is fairly straightforward:
We must have a notation, to specify things.
When we're specifying data or programs, the notation is almost
always
text of some kind.
(Well, it could be done with tables or diagrams, but that's
uncommon.)
The notation is designed for TWO purposes: to be read by people,
and to
specify whatever it is.
We can almost always design the notation so that both purposes are
served conveniently.
The design of a notation is its syntax. The stuff it specifies is
the
semantics.
[Richard Anthony Hein]
I understood this much ...
It is usually possible to specify the stuff, and still have
considerable
room for manoeuvre in designing the semantics. This is nice, because
then we
can make the language more readable.
For instance, we can have white space and indenting.
But the semantics should be the same, regardless of syntactic
niceties
like whitespace.
Now it turns out that the official specification of XML specifies
the
syntax, only.
[Richard Anthony Hein]
I didn't actually realize this ...
We assume that parsing an XML document builds a tree structure
(that's
the semantics),
and usually it will, but the XML specification doesn't say that
it must.
This was also the case with SGML - and that caused confusion,
because
different development teams were intersted in different aspects of the
semantics.
It meant that different teams would build parsers differently,
and each
would be satisfied with the results - but they couldn't share working
code,
because they had built different styles of XML trees.
Groves was invented to standardize the semantics of SGML, so that
such
confusions couldn't arise.
It can do the same for XML, if need be.
Groves defines semantics only.
[Richard Anthony Hein]
This is a key point, and how simple it makes everything now that
you
have said it! I never grasped this out of Paul's paper. I had an
idea of
what Groves really meant, but it involved syntax as well, so this
clears all
that up and makes it all very clear to me!
The purpose of it is, to determine the properties of the elements
of
documents. Then there can be no question as to what XML files (that
is,
source files, in readable text) are supposed to represent.
Or to put it another way, there can be no question as to what an
XML
parser is supposed to build.
(There is a quibble, which can be confusing. In some cases, we
want our
programs to work on a semantics of characters, not tree elements. For
instance, parsers themselves. Their purpose is to create semantic
structures
according to the syntax of the source text. Therefore, their
implementations
must be programs using character and string semantics. Don't worry
about it,
it's a quibble.)
The intention is that XML syntax should be parsed so as to
produce trees
with precisely the semantics defined by the XML groves property sets.
Knowing this, confusion between XML syntax and XML semantics is
dispelled.
[Richard Anthony Hein]
Excellent.
Another thing that groves is good for, is defining alternative
versions
of a standard semantics, for different purposes. These versions are
the
alternative views, which Paul speaks of. Some applications only need
to know
about certain properties of (e.g.) XML trees, and can filter out the
rest,
for example.
Finally, since groves defines the semantics, groves can provide a
unique
semantic identification of every element in a document - an address.
To
define the semantics of a structure is to provide a complete
addressing
scheme for it.
So, groves are useful. Using them, we can state exactly what we
mean by
an XML document, exactly how to build it, and exactly how to identify
each
part of it.
The question I was keeping an eye on was, Is groves the ONLY
complete
description of XML semantics?
[Richard Anthony Hein]
Surely there are other ways, but they may just be reinventing
Groves,
like Paul mentions in his article. There may be a need to reinvent
Groves
for XPath, XPointer and XLink, but in the end it will probably retain
it's
fundamental nature, and end up looking pretty close to what it does
now.
Since XPath, XPointer and XLink are not finalized yet, it would be
beneficial to discuss this with the working groups, in their forums,
to find
out what they think about Groves, and how they see it relating to the
specs.
After all, up to a certain point, people were happy to use the
DOM -
which defines document semantics in terms of interfaces, made up of
operation declarations (method call formats) in IDL (Interface
Description
Language). Paul objects to the DOM because there is only one of it -
where
with groves, we can define many different interfaces (alternative
views).
I'm not sure we couldn't get a complete semantic definition, with
alternative DOMs, one for each view.
[Richard Anthony Hein]
But wouldn't this mean having more things to worry about? Groves
look
like they are one thing, while multiple DOMs sound like they would be
different, and require more knowledge, time and effort in order to
learn,
understand and implement. Perhaps I am wrong here, but why make
multiple
DOMs to describe something one method of creating Groves can do? I
can't
stand having 500 different ways to make an e-commerce site ... what a
pain
to try to figure out what technologies to even start with. I wish
there was
only one way that made sense - one of the reasons I went for XML ...
it is
one thing that describes all kinds of ways to do lots of things, but
if you
understand XML, you can understand all the others (in theory at
least).
But another candidate for a complete XML semantic definition is
XPath,
etc. There has been considerable progress with these since Paul wrote
his
article; by now, it may be that XPath can address everything in an XML
document that can be addressed; while XPointer can allow auxiliary
addressing schemes within documents, and XLinks can extend addressing
to
other documents.
[Richard Anthony Hein]
This is an important point ... better than making multiple DOMs I
think,
is to be able to use XPath, if it can do what Groves are supposed to
be able
to do. If anyone knows better than Jonathan and I about XPath and
Groves,
please speak up. If not ... let's go to the source.
Once Paul had gotten through an explanation of how groves are
constructed, I was convinced that they are indeed a complete semantic
description.
Futhermore, it is a description in very simple terms. Everything
you can
say about an XML document type can be defined in terms of name-value
pairs.
That means that if need be we can prove the correctness of the
programs we
write - and especially the basic XPL tags we define.
However, being low-level, it is also very tedious to read.
[Richard Anthony Hein]
True enough, name-value pairs is simple - it can't get much
simpler.
Tedious to read ... true, but wasn't that program Paul talked about
supposed
to document Groves automatically, since they are essentially
self-documenting? Besides which, C++ and Java are pretty tedious too
for
someone not used to it. Put together a self-documenting IDE for
Groves,
that documents the Grove (in a manner not unlike the link Paul gave)
you are
using on the fly in a side box, and it'll be easy enough. I think.
What I hope, is that XPath etc can eventually be defined in groves
terms, and show to be correct, and maybe also to be a complete
semantic
description. Because Xpath etc will usually be a much easier form to
read.
The more we can get all this straight in our heads, the more
effective
our discussions will be.
[Richard Anthony Hein]
Yep.
Enough for now
Jonathan
I also think that the newer XPath and other related
specifications may
do some of the things that we need for XPL, and I will do whatever
research
I can into these areas. Since Paul wrote in his article that comments
were
welcome, perhaps you should send him an email with a link back to your
annotations to his article. He would surely be able to help clear up
some
of the questions and concerns you bring up; maybe he'll even join the
group
(the author of WorldOS joined now, which is cool and a nice
surprise).You
wrote in your annotations that you have a lot of compiler
experience ... do
you have any suggested sources to look into to get a better idea about
compilers and even perhaps "how to make a computer language" type
information? :-) I still haven't a clue how you can make up a
syntax and
semantics, and build a compiler to translate it all to machine
language.
Don't you have to use an already existing language such as Assembly
or C to
do make the compiler? Probably a really stupid question, but I
transfered
out of computer science and into neuroscience (which would explain my
interest in your XPL-fog posts. I started CS with the intent to go
into a
neuroscience MS afterwards, hoping to work on neural networks and AI,
but I
switched into Nesc. early - I blame it all on my boring COBOL co-op
term and
all the really unhappy programmers working there), so I never got
that far.
:-(I will be going back to finish up that plan once I pay back the
money I
already owe, and save enough to go back to university.
Sincerely,Richard A.
Hein
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|