RE: infinite depth to namespaces

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

As one who, I suspect, is considered in favor of the "rigid model envisioned
by a schema author", I'll answer this.  It is unquestionably the right of
the application to internally process documents any way it wishes.  The
model envisioned by the schema author, as exploited by the document author
as a means of conveying meaning (intent? something? whatever) is an input to
the application - something the application might find very handy in
processing the document (where the PSVI may be useful), but something that
may be ignored.  I have no problem with XSL on these grounds any more than I
am concerned with the synaptic connections in your brain that are firing now
in connection with this email - privacy of your own home/processor and all
that.  My goal is to better enable authors (of schemas and instances) to
better convey their intent (whatever that means) and allow application
authors to exploit that to write better applications more easily - I'm a
toolsmith.  While I'm not personally a big fan of the PSVI, I do know that
it's not intended to straightjacket anyone.

However, while I'm not at all concerned with what you do with information
internally, externally I'm very interested in how you behave if we're to do
business together.  It's important that you adhere to schemas we've agreed
to use, or my job of understanding you becomes very difficult.  This is
especially true if we're to do business in a community with many
participants - I can't possibly afford to build one-off processors for
everyone I do business with.  That's the bane of EDI.  And that, by the way,
was _my_ major use case for building XSDL as we did.  For internal
processing, I'd be much more interested in using type inferencing
mechanisms, etc., that are much more flexible that XSDL.

Matthew

> -----Original Message-----
> From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
> Sent: Thursday, August 30, 2001 2:29 PM
> To: 'Simon St.Laurent'; xml-dev@lists.xml.org
> Subject: RE: infinite depth to namespaces
> 
> 
> > From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> 
> <snip/>
> 
> > More recently, the unqualified-names-in-qualified-context has led us
> > back to circling round and round.  While I'm glad to some 
> > extent that my
> > filters produced real (and occasionally outraged) response, I 
> > also hoped
> > that they might in some way represent an escape from the complex
> > implications of the subject. By providing conversion from 
> one view of
> > the naming universe to the other, I hoped that maybe we could 
> > evade the problems.
> 
> I think you are on the right path. I did not think so 
> initially, but it
> didn't take much for me to come around and agree with the 
> notion that it is
> entirely appropriate for applications to adapt the view of an 
> infoset to
> suit the application's processing needs, rather than insist 
> that any XML
> application must adapt its processing model in every case to 
> suit a rigid
> model envisioned by a schema author.
>  
> > However, it seems that there are many of us who are uninterested in
> > escape. Some would rather turn toward an equally endless 
> > subject, PSVI,
> > to build solutions they think will work for their particular needs.
> > Others simply don't mind the ambiguity involved in using unqualified
> > names, knowing that their software will deal with it.  (They 
> > don't seem
> > especially concerned about other people's software.)
> 
> This is the problem. One has to wonder why these people are 
> not objecting
> strenuously to XSLT. Why there is a technology for which the 
> entire intent
> and purpose is to muck with someone else's infoset.
> 
> The problem is, if we yield to these notions, XML does not have a very
> bright future. The consensus that some are trying to achieve 
> on the matter
> of what is the correct practice for the one information set 
> all schemas
> should present to all applications is simply not achievable. 
> Insistence on a
> single inviolate PSVI to which all consuming applications 
> must adapt their
> processing model will always be an endless source of 
> contentious debate, and
> resolution one way or the other can only disenfranchise those 
> who need a
> different processing model. This can only lead to fragmentation.
> 
> Given that one of the key attractions of XML is its malleability, this
> strong sentiment against malleability seems to me to be silly 
> and deeply
> misguided.
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>