[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Micah Dubinko" <micah@dubinko.info>
To: "XML Developers List" <xml-dev@lists.xml.org>
Sent: Tuesday, September 13, 2005 5:15 PM
Subject: [xml-dev] List of XML-Dev permathreads
>I note with some sadness that Alaric Snell's "XML-Dev Permathread" page
>(http://www.alaric-snell.com/xml-dev-threads.html) has gone back to a
>NetworkSolutions/domain parking page. I mean c'mon--nobody uses Network
>Solutions to register domains any more.
>
> Slightly more seriously, here's a Wiki-editable copy of the page for
> reference, retrieved from a cache.
>
> http://wiki.brainattic.info/XML-Dev_Permathreads
>
> Feel free to edit. Thanks!
>
cool, now probably we need to argue about this ....
hmm, I will now express my oppinions.
for all those that don't care, I will probably dissapear again once I lose
interest...
> 1 Tight vs. Loose schema coupling
dunno, I don't really like schemas.
I guess for some things they are likely quite useful, eg, data binding.
I don't want to be expected to use them, partly because I don't need them.
> 2 XML: Data model or syntax?
both maybe?...
actually, I view it more as a data model myself.
it is supprisingly capable imo, and eventually displaced my preference for
s-expressions partly because many of the same points where xml seems to fall
short (no builtin type system, the attribute/namespace issues, ...) also
seem to be signifigant sources of "power".
> 3 Should we standardise easily processed / randomly accessible / more
> compact / simpler serialisations of the infoset?
imo: yes;
with free and online spec as well;
with some compelling reason to actually use it;
with a design I can at least tolerate;
with a spec that is fairly short and "to the point", vs the long-winded
psuedo-legalese type crap I tire of reading sometimes (likewise, the spec
should be generally readable as well, vs some I have read which attempt to
use abstract notation as an alternative to writing a sensible
description...);
..
in particular, it needs to defeat my not-invented-here tendencies.
well, this is part of it...
now, I don't feel a "one size fits all" approach is going to work, likely,
this may require several different formats for different uses (eg: like it
is with graphics formats, eg, we have: jpg, png, gif, targa, bmp, ... all
with different uses in different cases).
just, if something "good" is came up with, I may use it.
> 4 Should a URL be resolvable?
> Can something syntactically a URI be used as a URN?
for namespaces? imo, no.
what is it supposed to resolve to exactly? the schema, a spec, or what?...
actually, I like the definition of it being a magical string myself, I don't
have to worry about what it is or where it refers to, more just that it
needs to be equal.
> 5 Element versus Attributes
imo, attributes are useful.
they are likely not strictly necessary, but they are just so damn useful,
eg, for tacking on misc bits of data to various tags.
> 6 Binary XML
this different than 3?...
> 7 XML Namespaces
I like namespaces myself.
imo, they are quite useful.
imo, they should be part of the core spec.
> 8 Complexity of XML Specs
yes, they could be shorter.
I can also imagine a few things that could be removed (in my case at least):
dtd's (instead, opting for real schemas);
user-defined entities;
doctype, ... (instead opting for using the root a namespace);
..
so, basically, only the basic syntax, a few predefined entities/escapes,
namespaces, and maybe a few other things would be left.
imo, weird stuff, eg, merging entities and namespaces, seems like a bad
idea...
imo, the syntax should be backwards compatible. anything in the new syntax
should parse fine in the old parsers.
actually, imo, I am allready using something like this. a lot of times, bits
of xml syntax are just ignored anyways by my parser, and are not generated
by my printer.
well, I have my oppinions at least.
> 9 Semantic Web
dunno.
> 10 Is XML too hard ?
dunno.
it could be a little easier, and the specs could be a little less imposing.
|
