xml-dev - Re: XML API specification

[Peter@ursus.demon.co.uk (Peter Murray-Rust)]

Richard,
	This is very helpful.  It is probably patently apparent that I
am struggling with groves, grove plans and so on.  I am also struggling
with the SGMLPropertySet.  It is clear to me that a very high priority
for people like me is a 'Gentle Introduction to Groves and PropertySets".
(Even if I could manage all of 10179 it's difficult to tell what is 
_important_ and what isn't :-).  I notice that the property set is itself
ISO:17044 - does that mean it's an add-on to 8879?)

	As always I present myself as an archetype of someone who has 
encountered SGML pragmatically and takes it as a voyage of exploration, 
going as far as is necessary to solve a problem.  It's therefore a process
of gradual extension of knowledge.  Take my position as someone who 
can run sgmls and use the ESIS output via CoST (Joe English's version).
My education is largely due to Joe's documentation and many helpful 
e-mails :-).

My current understanding (PLEASE CORRECT THIS ANYONE!) is that a normalised
WF XML document is isomorphic to its ESISStream.  IOW having read the
XML document, applied any conditional clauses, substituted any entities,
the XML document contents can be automatically converted to ESIS and vice
versa.  [The reason this matters is that until recently I have been using
sgmls to parse CML and input the ESIS into my tools.  I also have a crude 
XML-like parser :-).]

I think there will be quite a few people who think along these lines - 
the SGML/XML is validated and transformed into a single ESIS-equivalent.  At
present it's adequate for my (limited) requirements.

My very crude vision of groves is that these are a set of tree-structured
views of the ESIS/XML tree, with properties being added at nodes for various
purposes that I do not yet understand.  Am I on the right lines? :-)

In message <tn+$1EAWTVFzEwqR@light.demon.co.uk> Richard Light writes:
> In message <4028@ursus.demon.co.uk>, Peter Murray-Rust
> <Peter@ursus.demon.co.uk> writes
> >On the general strategy, I think that it's important (though difficult) to
> >balance the needs of a global approach (using groves, etc.) and something
> >that implements PhaseI.  I'd like to argue for a PhaseI tool, partly 
> >because most of it is there in pieces, and partly because the rest is
> >at the mercy of the final spec.  There will also be some users of XML who 
> >are quite happy to stay with PhaseI software for their problems initially
> >and move on as they see the need.
> 
> I don't claim to have fully grasped the mechanics of _applying_ grove
> plans, but isn't the principle that you use them to specify which subset
> of the SGML property set you want in your output grove?  If so, can't we
         ^^^^^^^^^^^^^
This is a beast that I don't understand, and would be happy for an 
explanation.  Since (I don't think) it occurs in PhaseI it's important that
we make sure that any implementation of PhaseI-only material can be 
understood from the spec.

> say that our PhaseI requirements are a 'grove plan', then use the
> relevant bits of the SGML Property Set as the primitives for our 'data
> structure' API?
> 
> Does the SGML Property Set contains all the data constructs and
> properties we are interested in from an XML perspective?
> 
> I'm not suggesting that the structures and their properties should be
> expressed as in the DSSSL standard (Section 9.6 - horrendous!), but if

Ah... I am looking at the section.  This was a bit I hoped was 'unimportant'.
The XML-WG has been debating whether conecpts from standards outside XML can
be used without being explicitly in the XML spec.  I would hate to think
that XML implicitly involved 10179:9.6.  I can accept that it may/will come 
into PhaseIII.


> that section of DSSSL contains a complete description of all the
> concepts we want in the XML API, we simply have the job of re-expressing
> them in a different notation.  This could even be reduced to a
> mechanical process.

A human translation of 9.6 would be valuable as well :-)
> 
> That is _much_ easier than re-inventing them all.  It also means that we
> have a painless method of extending the API: we simply add to our grove
> plan and pull in the extra concepts.  It also aligns the XML API as a
> practicable implenetation of a (useful!) subset of the standard SGML
> Property Set.

I will have to leave this to others :-)

The key questions seem to me to be:

'Can we provide an API for PhaseI, as it now stands (with any minor
future revisions to the spec)?'.

'If we create such an API is it _extensible_ to PhaseII and/or PhaseIII, 
when we are not clear of their final detailed shape?'

My gut feeling is that a PhaseI API can be extended to a PhaseII API
without breaking it seriously.  (We shall doubtless define things like
Link, MultiLink extends Link, etc.)  It seems (again from my position of
ignorance) that your concern is 'if we create an API for PhaseI and don't
think about the effect on PhaseIII, we could find ourselves in serious
trouble'.  I can't help there.  However if we _can't_ easily extend
NXP, Lark, etc then we are going to have a fairly hairy system to work
with.

	P.


-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)