RE: [xml-dev] Symbol Grounding and Running Code: Is XML Really Extensible?

["Dare Obasanjo" <dareo@microsoft.com>]

Your position seems to be about sharing object models so that various
XML application languages can be extended by vendors. This is something
I'm not particularly interested in and think is a horrible idea for XML
formats for news syndication. It may be of use for specific XML
vocabularies to define such extension mechanisms and API plugin points
as the RELAX NG folks have done but I don't think this is any sort of
general solution nor do I think it should be encouraged for XML formats
designed for data interchange to require interoperability at the API and
object model level. 

I guess this is where I bow out of this thread. 

-- 
PITHY WORDS OF WISDOM 
Eat right, Exercise, Die anyway.


This posting is provided "AS IS" with no warranties, and confers no
rights. 

 

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com] 
> Sent: Wednesday, August 13, 2003 10:52 AM
> To: Dare Obasanjo; Alaric B Snell; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Symbol Grounding and Running Code: Is 
> XML Really Extensible?
> 
> From: Dare Obasanjo [mailto:dareo@microsoft.com]
> 
> >Alaric doesn't posit a general solution which is what my 
> original post 
> >is about.
> 
> He began by positing that a solution is possible.  That was progress.
> 
> >Anyone can come up with an namespace-based extension 
> architecture for a 
> >specific XML vocabulary where extensions perform a single specific 
> >task. The RELAX NG folks have shown us how to do it already with 
> >pluggable datatypes based on namespace URIs. Something 
> similar could be 
> >built into XSLT and W3C XML Schema engines if the user 
> demand for such 
> >features was that significant.
> 
> Can it be built into ANY XML application engine?  That would 
> be progress.
> 
> >However such specific implementations aren't really relevant to the 
> >original discussion which was about how to signify "meaning" in 
> >something like a syndication feed which could be extended in any 
> >possible direction as opposed to one narrowly focused direction.
> 
> It isn't?  How does one extend an XML application language?  
> They add elements, attributes, etc., and if they aren't 
> extending the language at the standard source, they do it by 
> adding namespace-qualified elements, attributes, etc., but 
> then they also have to figure out a way to get someone to use 
> their objects or to get their objects onto the end user's 
> desktop.  These objects must plug into the object model the 
> end user has, or the end user has to replace the whole object 
> set for that application.  Seems clear enough.
> 
> >Of course the original discussion is pipe dream Semantic Web 
> goop while 
> >this discussion is actually of practical interest.
> 
> Any discussion of general semantics, particularly of the 
> human kind, has to face up to the fact of abduction as the 
> initial process, and go from there.  If the Semantic Web has 
> a flaw that bedevils some, it is likely in confusing content 
> systems with network systems and claiming they are the same.  
> In some aspects of model theory, they are; when it comes to 
> implementing the running code, they aren't. 
> Unification by sharing the naming system won't fix that.
> 
> > Dare:  Internet Explorer.  See the means for annotating the 
> presence 
> > of VML in an HTML document.
> > Big surprise.  It uses a namespace declaration. 
> 
> >I don't consider this embedding semantics. This is simply a 
> rendering 
> >engine delegating rendering of embedded markup to plugins based on 
> >whether it has or knows of a renderer for the embedded 
> markup. The fact 
> >that VML in IE requires you to put the VML namespace decl on 
> the root 
> >element of the HTML page is probably more for practical reasons 
> >(performance, initialization, etc) than anything else.
> 
> I do consider it semantics because it is behavior.  That is 
> significant. 
> That it resolves to the rendering behavior (a particular 
> semantic) is practical.  That it uses namespaces to name and 
> bind the behaviors is exemplary, that is, an example of a 
> practice that goes beyond namespaces as mere syntax.  From 
> the point of view of the XML specification, they are just 
> syntax.  From the point of view of an implemented XML 
> specification, they are names for behaviors to bind from the 
> parse results.
>  
> >> So clearly namespaces rightly or wrongly, morally or indefensibly, 
> >> big endian or little endian, without regard to the 
> philosophical or 
> >> legal or sanctioned efforts of the
> ?> standards committees ARE BEING USED TO ATTACH SEMANTICS TO 
> XML TAGS.
> 
> >Namespaces attach some form of identity. Without this identity
> >processors of XML vocabularies would not be able to process XML. How
> >does a W3C XML Schema validator or XSLT transform engine determine
> >whether it has a schema document or stylesheet? By the local name and
> >namespace name of the root element of the document it has been fed. 
> 
> Identity, sort of.  They build up properties such that one can 
> determine they are a member of a set.  They name a set.  The 
> identification of any named element is then performed.  No 
> identity without identification.
> 
> >As Tim Bray said, namespaces aren't relevant to the symbol grounding
> >discussion and just add a layer of indirection. 
>  
> Respectfully, what one does with symbols, and namespace identifiers 
> are symbols, is something the specification Tim wrote is quite 
> silent about.  Tim is due his own opinion there, but the 
> specification, 
> once published, is independent of the author's opinions.  
> Weird, but so.
> 
> He isn't wrong.  It is simply that there exist 
> counter-examples in the 
> wild and if we build by common practice, such practices are emerging 
> and I have cited some examples.
> 
> > One needs a way to describe an abstract object 
> > model of the browser that is mappable to the XML namespaces 
> > and by which, one can easily declare meaningful combinations.
> > 
> > RSS won't be extensible in and of itself without something 
> > similar.  We really must differentiate XML language design 
> > from XML system design.
> 
> >A web browser does one thing and one thing only; render markup. It is
> >trivial to design a system that says render markup from 
> namespace A with
> >engine A and markup from namespace B with engine B modulo some
> >constraints with regards to location of embedded markup. 
> 
> No, it is also a vehicle for delivering applications.  Your 
> company just 
> lost an expensive lawsuit to EOLAS because of memos your 
> managers wrote 
> describing precisely that functionality.
> 
> If web browsers only rendered markup, things would be much 
> simpler.  Both 
> MS and Netscape and others went beyond that and there is no 
> going back.
> 
> >RSS feed aggregators do not perform a single task with the 
> markup in an
> >RSS feed and can perform any one of dozens of things with embedded
> >markup. 
> 
> Right.  Now, how shall they use namespaces to indicate extensions? If 
> they don't (and some think they shouldn't), then how does an RSS 
> vendor extend the vocabulary without a common object model?
> 
> Some will argue that they shouldn't.  Ok but that will splinter 
> RSS into a million variant languages.
> 
> len
> 
>