Re: A little courtesy, please

At 04:48 PM 2000-05-23 +0100, David Carlisle wrote:
>
>> How may I, without violating civility, indicate that this is not
>> universally regarded as an unmixed blessing?  Actually, Simon's approach is
>> clean in this regard because the actual damage is when namespaced names are
>> used to control styling directly off the syntactic analysis, with a
>> guaranteed non-dependence on any sort of schema backing up the names in the
>> namespace.  This is likely to adversely affect the disability interest.
>> The architecture should, to the best advantage of the disability interest,
>> direct styling to the "highest available infoset" for its input, and not
>> hardwire it to the lower-layer outcome of syntactic processing alone.
>
>Sorry, you lost me, could you expand that.

Thank you for asking, let me try to clarify.

>I _think_ that you are saying that you would have prefered the namespace
>rec to have mandated the existence of (something) as a retrievable
>resource located at the namespace URI.

That actually exceeds what I [just one vote] would prefer.  I don't think
(personal opinion) that it is wise for the definition of the
language-building mechanisms to universally require anything that narrow.
A 'should' clause is as far as I would go, not a 'must' clause.  We have
experience with the 'ALT' attribute in HTML.  Making it syntactically
required tends to generate a lot of syntactically conforming but
semantically useless attribute values in document instances.

What I actually _would_ have preferred is that there had been an "XML
Module definition and use" application profile covering both syntactic
markup mix/match features and semantic extension features that would be
accessed using the syntactic mix/match capability, written and reviewed as
a package.  This could have been written as multiple specification modules,
but should have been through-composed and reviewed as a solution bundle.
This says that neither RDF nor XML Namespaces should have been treated as a
severable work item.  But this is 20:20 hindsight.  
Given where we are, not where we could have gone, I _am_ very interested in
minimizing the extent to which we have to go back on our word, and a) look
at the combined-use scenarios that work b) find any failure modes in the
margins of the pattern of constructive combined-use scenarios and c) move
to make the avoidance of the failure modes more and more automatic through
_with all deliberate speed_ phase-out process provisions.

>I am sure that that much of a change is too much of a change to be
>considered, but forgetting that for a moment, I am interested in
>why you say that this would be better for disability interest.

I am about to post one or more examples separately in response to a similar
question from Simon.  Please watch for following mail marked (use case for
XML semantics).

>I more or less understand the last sentence quoted above as saying that
>you need flexibility in styling possibilities, but I am missing
>something that you have in mind as I don't see any connection between
>that and whether there is a retrievable resource at the namespace URI.


Break this into two parts:

a) whether there is a universally-implemented mechanism for linking to some
document [schema broadly construed] which adds knowledge to the context for
processing the names in the current XML-instance document.  This is
crucial. Refer to table semantics issue.  html:th and html:col e.g. have
semantics that is essential to capture, impossible to express via syntax
alone; need semantics attached to element type names to complete the
appropriate XML module. 

Note/drivel:  The access path to semantics is a requirement; layering the
system so that it is possible to process the syntax without fear of
contradiction, independently from access to the [schema or eq.] semantic
extension is something that, while it does not flow automatically from this
requirement, can [happily] be stipulated as a constraint for other reasons
without materially impairing the ability to satisfy this particular
requirement.

b) whether that mechanism uses dereference of something related to the
ns-attr as the "connection to further knowledge" or not.  Using the ns-attr
to contain the identification of a recoverable resource is a practice which
(1) has some advantages sometimes (2) has some disadvantages sometimes, and
(3) is not by itself critical or required under my reading of the
possibilities for satisfying a) above.

>
>Confused
>

Thank you for asking these questions.  Where there is one willing to ask,
there are generally ten confused lurkers as well.  I hope I am making
progress on making things clear.  I don't assume I can put all questions to
bed in one iteration.  These questions were a big help to me in
articulating what I am trying to say.

Al

>David
>

Received on Tuesday, 23 May 2000 13:37:26 UTC