[
Lists Home |
Date Index |
Thread Index
]
i do not understand how to reconcile these two statements:
David Carlisle wrote:
> You seem to be assuming that XST processing is interleaved with the XML
> parsing of the stylesheet. This isn't always the case, MSXML for example
> aways just uses a complete DOM as the input stylesheet: that DOM could
> come from anywhere. ...
...
> But your comment seems to imply that in the current specification you
> think there is something unpredicatble (rather than something that you
> think is a poor design). It is not at all clear to me that this is the
> case. An XSLT stylesheet can always generate a result tree containing
> the namespace information required. there is some unpredicatbility over
> the linearisation but all allowed linearisations would have sufficient
> information to ensure that any required namespace declarations will be
> present in any linearisation of the output.
>
> David
Michael Kay wrote:
>
> > isn't any application better off processing the specialized values in
> > the parser's dynamic context than trying to resolve the conflicts
> > inherent in dragging that context around indefinitely? from the
> > descriptions which i have seen, the status of such values is known at
> > the point where they are parsed. are there cases where that
> > is not true?
>
> yes, if the value has been blindly copied by an application that didn't know
> that the value had a dependency on the context. That's exactly what the
> whole XSLT-namespace problem is about.
>
the XSLT-namespace problem is more fundamental. it is not confined to
XSLT. the problem is that XML standards, and consequently many XML-based
applications specify in terms of concrete syntax something which can be
specified reliably only in terms of semantic domains.
would one try to express metacircularity in terms of concrete syntax?
this is not something which one can "fix". it is something which one can
stop doing.
the present state of affairs is as if one were to write an application
in terms like
(defParameter *package-name* "COMMON-LISP")
(defun do-something (with-this and-that)
(funcall (intern "+" *PACKAGE-NAME*) with-this and-that))
(do-something 1 2)
and hope to predict the result, when the language permits
(defPackage "NEFARIOUS" (:use))
(defun nefarious::+ (&rest args) (apply #'common-lisp::- args))
(let ((*package-name* "NEFARIOUS"))
(do-something 1 2))
to date, the XML community responds to observations of this sort with
something like, "yes, this is ok. this is the way it should be."
sometimes the response is, "this is the way it has to be."
for example, when considering how to implement xslt, one can conceive of
an abstract syntax for xslt expressions which permitted an expression like
({xsl}element ({}name "xsd:QName"
{}use-attribute-sets "nsp1:attset1 nsp2:attset2")
"nsp3:name")
an implementation which were expressed in terms of this abstract syntax
would be conformant, but flawed. a better implementation would specify
an abstract syntax which required an expression of the form
({xsl}element ({}name "QName"
{}namespace "xsd"
{}use-attribute-sets ({namespace-name-1}attset1 {namespace-name-2}attset2))
{namespace-name-3}name )
or
({xsl}element ({}name {xsd}QName
{}use-attribute-sets ({namespace-name-1}attset1 {namespace-name-2}attset2))
{namespace-name-3}name )
and specify its semantics in those terms. this applies to both the
expression of content and the expression of markup. should one goal of
the larger application be to permit computations on xslt expressions
themselves, this second implementation would have much to recommend it.
in particular, in constrast the the former implementation, one would be
able to predict the integrity of the result beyond its surface syntax.
should the community ever come to the conclusion, "no, xml-based
applications should not be expressed or implemented in terms of concrete
syntax," one consequence is that NS 1.1 explicitly specify that the
binding of a prefix to a namespace name has dynamic extent. the only
standards which could then mention QNames would be the recommendations
on xml1.1=(1.0+namespaces) and on canonical serialization. this refers
to QNames in the sense of qualified names as specified in terms of
concrete syntax in REC-xml-names-19990114. the term "prefix" would
appear in no standard which did not concern itself with either parsing
or serialization. unfortunate terms like (expanded) qualified names
which appear in standards like those on xml query and schema data types
would be eliminated in favor of a term like universal name, which
concerned a names's local part and the namespace name only.
...
|
