Re: Clark's commentary

/ "David Orchard" <> was heard to say:
| Here we get into the excellent discussion of what features are being used.
| Sorry Norm, but your iotas don't quite match my iotas.  Which isn't
| surprising though ;-)

I think you missed my point. No one's iota's will match up, which is
why the only (IMnsHO) practical way to achieve success would be to
assert that *no one's* iota's get addressed. It's either an editorial
exercise in spec merging and clarification or it's dead in the water.

| 1) PI's should be removed as well.

<rant>Why!? PIs are *useful*. I *do not understand* why some people
want to remove them. Just out of curiousity (this is going to start to
be off-topic, so a motion to take this into private email would be
entirely in order; I'll leave this reply public on the off chance that
there are others who want to chime in :-), how do you solve the sorts
of problems for which PIs are useful without them?

Consider, for example, the case where you'd like to influence how a
formatter should present a title:

You want to format a document that contains the following markup:

  <chapter><title>How To Format Widgets in SomeFunnyProduct</title>

Left to its own devices, the formatter in question produces:

  How To Format Widgets in

But some copy-editor says, make it break like this:

  How To Format Widgets
  in SomeFunnyProduct

So you introduce a PI and key off that.

  <chapter><title>How To Format Widgets <?lb?>in SomeFunnyProduct</title>

What would you do instead?

| 2) Why not add XML Schema?  Or should that be in an xml post 2.0.  Or maybe
| we have well-formed xml 2.0 and valid xml 2.0.

Because W3C XML Schema are not necessary to use XML.

| 3) By dropping DTDs we lost modularity.  Whether modularity should be
| addressed in an xml 2.0 is an interesting topic.  One possibility is that an
| xml 2.0 could define a default processing model for inclusion.

As I said in my reply to Tim, I don't think we can drop DTDs.

| A nice facet of xml (2.0 = 1.0 - DTDs - PIs + namespaces + infoset + xml
| base) is that I think it more closely mimics standard practice, for example
| SOAP 1.2.

SOAP 1.2 standard practice is hardly standard practice for XML!

| This is an excellent example of architectural refactoring that often happens
| in software.  SOAP 1.2 had to invent the equivalent of XML 2.0 for what it
| needed.  Now it turns out that other people could use the same definitions.
| So let's refactor the XML 2.0 stuff into a coherent piece, then SOAP WG
| doesn't have to document it/maintain it.  And other specs can use it rather
| than copying the verbage from soap 1.2.

I'm horrified by this prospect! The use of XML in SOAP has to be the
definition of a narrow, application-specific vocabulary with little or
no broad applicability beyond RPC.

To base the underlying standard for an entire, wide-ranging, highly
adaptable, diverse web of applications on that single use case would
be foolhardy at best. IMHO, of course. :-)

                                        Be seeing you,

Norman.Walsh@Sun.COM   | 'I have done that,' says my memory. 'I cannot
XML Standards Engineer | have done that'--says my pride, and remains
XML Technology Center  | adamant. At last--memory yields.--Nietzsche
Sun Microsystems, Inc. | 

Received on Monday, 7 January 2002 14:57:33 UTC