OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] List of XML-Dev permathreads

[ 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.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS