Re: RE: New/old pattern syntax, why can't we have both ?

Subject: Re: RE: New/old pattern syntax, why can't we have both ?
From: dvunkannon@xxxxxxxx
Date: Wed, 19 Aug 1998 11:42:51 -0400
James Tauber writes:
> Isn't this more work, not less, and still leaves the 
> _very_ undesirable situation of having "non-XML" XML? 
We already have a non-XML syntax for XPointers and I don't think anyone 
would want to argue for an XML version of an XPointer. 
My feeling on the issue is that a spec be developed for tree addressing 
patterns that serves the needs of both XPointers and XSL patterns. Such a 
spec could stand apart (but be normative to) both XLink and XSL. 

	Actually, I did raise this idea (XML for XPointers) privately with some people.
The best argument I heard for a compact syntax was that it would be easier to
fit into the value of an attribute.  With patterns now residing in attributes,
I'm not suprised it reappears in this context. However, I think it is completely
wrong. There is no merit in the "it takes too much space to state a rule"

	This is not an issue of file size. The only place I've seen sheer wordiness
raised in a relevant way is in the vector graphics standard re paths.
	This is not an issue of expressive power. Concision does not buy power.
	This is not an issue of software capabilities. No one is arguing that this
concise syntax is easier to parse, especially with an XML parser always at hand.
A stylesheet writing program is going to create either syntax 
	Is this an issue of how much a programmer can see without hitting 'page down'?
Give me a break. Eyeballing markup is always hard.

	Amen to all those that have already said this is a bad direction to take the
spec. Let me add that this syntax is much harder to document. With the XML
syntax, I could add comments liberally to explain the design choices of the
match rule. 

	If xsl does go the two flavors route, it should still be in agreement with
XPointer in both flavors. In other words, there should be a way to express
Xpointers in XML syntax. Such a capability would be useful perhaps in expressing
links that are out of band.
David vun Kannon

 XSL-List info and archive:

Current Thread