xml-dev - Re: SOX

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 07:30 01/10/98 -0700, David Brownell wrote:
>In the list of antecedents, let's not forget IBM's XML4J
>which has an "element factory" API for creating specialized
>elements. 

Totally agreed. I should have included xml4j in my list of element-oriented
approaches - I just haven't played much with xml4j. And this emphasises the
need for creating as much communality at present. My main motivation is to
be able to write things like MoleculeNode.class that can rely on a core XML
implementation to manage all the non-domain-specific stuff. (I don't
actually *enjoy* hacking namespaces, etc. every time they change :-). I'd
hate us to get to the stage where we have applications which have to be
labelled 'only processable with xml4j... xml-ea1 ... xxx ... jumbo' because
we all used different interfaces. 

Of course there is a level at which we move from an OpenSource-like set of
APIs and supporting code to manufacturer-specific toolkits, but I hope we
have still a long way to go in the OpenSource direction.

>Some of my current thought:
>
>- To the extent that we're talking about actual components
>  we are language-specific (preferably Java :-) but it could
>  be useful to think a bit more generally.

Agreed. 
>
>- I'd prefer to name element types as { namespace uri, tag }
>  rather than with compound strings or a flat namespace.

I think this is critical. Every time I now come to an elementName I groan
internally ("do I need to support namespaces at this point?"). I feel held
back in some things I want to do because if I don't get it right it will
cause pain later.
>
>- Issues include how to construct a given node, and (IMHO)
>  the desirability of specialized parse-time interactions to
>  affect/approve the tree(s) constructed.

'approve' means a form of 'validation'? - it seems a useful word.
>
>- Depending on special DTDs or DTD rules may be unwise in
>  the general case, and even in the typical one.
>
>- Most non-structural operations should be separated.  For
>  example, GUI stuff should all be separate interfaces.  Some
>  attention to delegation will be important.

I think most of us would agree on this separation. And I suspect that the
non-GUI stuff may be a good place to start.
>
>- Generating customized content.  It's no good solving only half
>  the problem, and customization during parsing is "easy" (as
>  suggested by all the results there).

Could you expand on 'customized content'? Does this mean creating
element-specific storage and additional methods?

>
>- Separating configuration issues (property file vs a more
>  structured XML file vs compiled in defaults vs inferring
>  mappings from packages, etc) from everything else will help.
>  A factory API helps a lot here.
>
>Clearly, I agree this is important.

Very pleased to have your contributions.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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