|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Is XML getting too hard?
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@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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








