[
Lists Home |
Date Index |
Thread Index
]
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
|
