XSchema Progress and Strategy (was RE: XSchema: existing ID attributes considered harmful)

[Peter Murray-Rust]

At 12:56 17/06/98 UT, Simon St.Laurent wrote:
[...]
>
>I'll make the change.  I think this opens up XSchema dramatically, making 
>possible and eventually compatible the currently-proposed nested model,
Paul's 
>rule based model, and several of the ideas I've seen for re-creating
parameter 
>entities. 
>
>The key in my mind remains making the declarations referenceable; the rest
we 
>can handle in successive specifications as needed.  I think we have a great 
>start here.

I agree.

Whereas I was (in general) worried about overextending ourselves. I like
PaulP's suggestion of the PATTERN/RULE adopted from XSL. My reasons are:
	- I need the XSL-type syntax for transformations *anyway*. [I hacked this
part from the 1997 XSL draft in JUMBO, but it was sufficiently unclear in
the draft that I never really used it.]
	- AS XSL is going ahead *in parallel* then adopting their syntax is very
valuable because:
		+ we can re-use code fragments (in both directions).There is a greater
incentive for people to implement XSchema.
		+ the 'learning curve' for XSchema will be less, because people will be
exposed to XSL syntax and concepts elsewhere and there will be tools,
tutorials, etc.

In general I am personally not making details comments on the XSchema draft
(I like what I see so far :-) because I may want to help resolve strategic
problems later on. 
		
Remember, of course, that we are likely to need some sort of reference
implementation. DavidM did this for SAX, and that makes a major impact. My
feeling here is that we should *identify* the software components that are
required and make sure that we aren't building up unforeseen problems. (I
don't think we *are*, but it's always easy to underestimate.) Of the top of
my head we shall need:
	- a DTD parser (for transformation to XSchema). Do we get everything out
of SAX (I haven't looked in detail)?
	- a tool for navigating the XSchema tree/patterns. Are DOM tools the right
thing? Can XPointer language do this? (I used this a lot in JUMBO1 -
haven't finalised XPtr for J2). e.g. find all RULEs within an ElementType
(or whatever).
	- something for interpreting the Rules
	- a DTD writer.
	- some simple transformations (e.g. XML2XML, XML2HTML (for docs). Maybe
SAXON has a role?

	P.

[I haven't finished my mail reading, but things look promising. Keep going!]

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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)