Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML API specification
 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@l...> Richard Light writes: > In message <4028@u...>, Peter Murray-Rust > <Peter@u...> 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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
