[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Proposal for src files

  • From: Peter Murray-Rust <peter@u...>
  • To: "W. Eliot Kimber" <eliot@i...>,xml-dev@i...
  • Date: Thu, 02 Apr 1998 08:51:19

src files
At 11:22 01/04/98 -0600, W. Eliot Kimber wrote:

>But maybe I'm just a crank.

No. But you have a level of vision and understanding that makes it
difficult for others like me to follow. This is a recurring theme in the
whole of current  IT/CS - there are 'right' solutions that people simply
are not able to comprehend or find too difficult to adopt.  In those cases
one ends up with a small number of people who provide a solution (often at
high cost) to a large number of people who don't understand an don't own
it. IMO the single most important thing about XML is that it makes things
accessible to at least a hundred times more people than other technologies.
We are seeing this debate frequently now - 'what does XML do that XYZ
doesn't?' My answer is that it can relate to ordinary hackers - and
possibly even to inspired management.


>At 09:22 AM 4/1/98, Peter Murray-Rust wrote:
>><PROPOSAL>
>>Is it possible to combine these two so that we express a DTD in a standard
>>XML notation? Many of us do this already, but I suspect that our tagset and
>>syntax vary. If we could agree on this - and I don't see this as
>>technically difficult - we could help both communities. 
>
>It is not technically difficult--it is, however, practically impossible
>except in the most trivial way (a direct transliteration of DTD syntax)

I was thinking of something very trivial (you didn't expect anything else
from me, surely :-) - a lossless translation of DTD to XML format (and vice
versa) without any inheritance, mapping, etc. I thought this was
uncontroversial - but maybe I haven't got my point over.

>unless it is *explicitly* defined as a base architecture with very clear
>rules for specialization. And even then, developing that architecture will
>be difficult at best.
>
>The reason it's practically impossible is because getting agreement among a
>community of interest as wide and varried as the XML community on a subject
>of such importance as how to represent the definitions of document types is
>one of the hardest types of things there is to do. There are simply too

I wasn't trying to tackle this. We already *have* a definition of document
types - it's XML 1.0. I was simply suggesting we standardised an XML-based
syntactic representation of this.

>many different ways to do it, too many different ways to represent things,
>too many interested parties. The degree of expressibility of schemas is
>open ended, meaning that any design, to be useful, must be maximally
>extensible. Defining extensible languages is hard.
>
>I personally think that trying to define a common markup approach to DTD
>representation is a waste of time: the answer is either obvious (Wayne
>Wohler did it over 5 years ago) or impossible to achieve consensus on. The

If it's obvious and already done, perhaps it should be re-used?

>first is not useful compared to the cost of defining and maintaining it,
>the second cannot be achieved by any sort of consensus-based approach. So
>there's no point in bothering. 
>
>The minimum abstractions needed to define element types are already defined
>by the SGML property set--if your schema language can get you to these
>abstractions, fine.  

Perhaps all we need is a representation of the property set in XML format.
Would *that* be controversial?

>
>I say let groups define their own schema approaches without bothering to
>find too wide of a consensus. If one particular approach gains widespread
>acceptance, then fine. If it doesn't, we're no worse off than we were
>before, *but* we haven't wasted a huge amount of a scarse resource on a
>doomed effort.  This provides opportunities for vendors to distinguish

Although I value your judgement, I don't see why this is 'doomed'. The same
could have been said about SAX. I'm proposing that we take simple steps to
see if there is a communality here that we can use.

I am not enthralled by suggested that we let anyone do whatever they like.
We can then guarantee that whenever we encounter a foreign schema it will
be another significant task to understand and code it. This would - as I
suggested - simple move the 'battleground' from tags to schemas. We have
avoided having parser wars with SAX and DOM - couldn't we at least look at
schemas?

I agree resource is scarce. I think SAX showed an excellent way of
conserving such resource. If we followed the same process we might find out
at an early stage whether we were doomed or not :-)


>themselves by providing different types of validation and constraint
>support. As long as they always support normal DTD syntax, I see that as a
>good thing--if someone like Microsoft produces a product that helps me
>create better data repositories, then I'm happy to buy and use it, as long
>it accepts and generates normal DTDs with the level of fidelity I require.
>But why should I give Microsoft (or anyone else) free engineering support
>by being involved in a schema development effort? It doesn't make sense to

We gave them (and lots of others) free engineering support for SAX. I put a
lot of effort into that and I'm not complaining :-) Actually even just for
me, the effort was less than writing APIs for every parser. Multiply that
by 10000...

>me. If they want my help, they can pay me.  I already have what I want and
>need and I'm capable of providing for myself if I need more (as is anyone
>with a copy of Lark and a Java book).

I'm afraid I (and I think many others) aren't :-) and that is why I raised
the problem. Being a part-time academic who does XML in their spare time I
don't have the resources of a commercial company - and I suspect there are
many others in a 'similar' position. They will come across 'schemas', 'src'
files, etc. and need to know what to do with them. I hope we have a more
constructive message than simply "wait and see what the large commercial
organisations do, and then buy their products" :-).  The WWW grew in large
part through the efforts of large numbers of large number of people who
picked up a common philosophy and developed it. If the message now is that
"unless you are a member of W3C you shouldn't be involved in XML
development" it represents the passing of an era, and I'll need to rethink.

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.