xml-dev - Re: Is XML getting too hard?

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

At 19:09 17/08/98 UT, Simon St.Laurent wrote:
>David Megginson writes:
>>What frightens me is the danger that some people might forget about
>>layering and try to overload the XML core.  XML 1.0 has some warts,
>>but in general, it's beautifully simple.  I have no objection to
>>seeing RDF, DCD, Namespaces, etc. built *on top of* XML, but I don't
>>want to see them built *into* XML -- imagine if every program that
>>worked with ASCII had to be able to parse C++ as well, or if every IP
>>router had to know about HTTP!
>
>David's got it right...

I agree.

>time. (_Expensive_ ones, anyway.)
>
>I think layering may provide an elegant answer to the schema/feature 

I agree with this analysis, and I'd like to see us tackle those components
which are isolable and can be prototyped at present. I know it's difficult
with most of them being in a fluid situation. I'd be also grateful for some
timescale on PRs, etc for these.

>clusterbombing we're experience now, though it too may require some 
>reconfiguration of XML.  Basically, it looks like we have:
>
>* Core syntax (<, >, / - elements, attributes, the XML declaration)
>* Minimization (entities and their friends, plus lots of other charmers)
>* Schemas (DTDs, DCDs, XSchemas, RDF, etc.)
>* Data typing (Goes with schemas, but I'd like to see it independent of any 
>particular schema)
>* Linking (XLink)
>* Referencing (XPointer) [Yes, I know I'm making a questionable distinction.]
>* Styling (CSS, XSL)
>* Core syntax extensions - namespaces, xml:lang, xml:space
>
>We need to find a way to keep these things separate while making sure they
can 
>work with each other, and not muddy the name XML too terribly. If 
>understanding XML is going to require namespaces and RDF, a lot of folks are 
>going to choke.  If XML is about elements and attributes and the rest of
it is 
>gravy, then I think we'll be all right.

Some of these are dependent on others, right? If so, which - because that
affects the order we start on. For example I suspect that XLink isn't very
much use without XPointer, but the reverse isn't necessarily true. (i.e.
one can envisage uses of XPointer without Xlink syntax).

I have a feeling that *if* we use prefixed names, then nearly everything
else is going to have to depend on how they are used. Similarly any
minimisation has to be resolved at an early stage.

>I was going to write a very grumpy essay about this, but it looks like
it's a 
>widely held concern that people in the right places will likely notice, so 
>I'll keep the fire and brimstone to a minimum.

Thanks. I think people will notice and will be grateful for constructive
ways forward. I suspect that those who drafted the latest WD are somewhat
exhausted by the process and would be grateful for help.

One idea that is worth exploring is how far we can get without using
complex constructs. 

The idea of bundling up many files - promoted by David Megginson - is an
exciting one. If I could be assured that I could send a jar file to a
client and they could unbundle it seamlessly and effortlessly then I might
very well eschew the complexities of namespaces (I'd still use simple
ones). Effectively each namespaced object would be a file with a unique
namespace. These could be referenced from the document either as NDATA (am
I right?) or by XLink.

 However I am not convinced that this is a good idea for storing files
client-side or manipulating them locally. Either they would remain as *.jar
- which are unreadable by humans - or they would be expanded to lots of
little files which could very easily get lost or overwritten. My own
suggestion would be for a 'multipart' file where the different XML
components were concatenated - perhaps even by special syntax. Then they
are both human-readable and physically bound.

	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)