[
Lists Home |
Date Index |
Thread Index
]
James, I've completely lost your thread. You're using terminology I don't
understand, and I don't know where it comes from. I've no idea what you mean
by metacircularity, for example.
The behavior of XSLT 1.0 stylesheets with respect to namespaces is
well-defined, the results are predictable, the implementations are
conformant with the specification, and on the whole the behavior meets user
expectations. Now what exactly is your problem?
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
> -----Original Message-----
> From: james anderson [mailto:james.anderson@setf.de]
> Sent: 12 April 2002 11:40
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] [good] Question about NS 1.1
>
>
>
> 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.
>
> ...
>
> -----------------------------------------------------------------
> 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 list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
