OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] [good] Question about NS 1.1

[ Lists Home | Date Index | Thread Index ]


The question remains, what purposes do static in-scope namespaces serve?

Michael Kay wrote:
> 
> > > 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.
> > >
> >
> > yes, but what value has been "blindly copied". where those attributes
> > values or element content which are declared to be in the QName domain
> > are processed in the parser's context, there are no lexical values -
> > which could exhibit a dependancy - to copy. where the application
> > introduces values it must introduce values in the correct domain.
> 
> What has been blindly copied is a text node.

Are there really cases where one copies text nodes from a context in
which a prefix had one binding to a context in which a prefix has a
different binding with the intent of effecting a change in the implied
universal names.

If so, is this really the best way to express the intent?
If not, then why is one copying text nodes?

> 
> (a) XML Schema wasn't around at the time XSLT was invented

It is around now. One doesn't need schemas. One need only to admit that
names are not text and accept that they need to be typed. Which is
nothing more than typing namespace-nodes.

If the application is not empowered by the parser to processes the
attribute and element content in the parser's context, then QName and
XPath types are needed. With the attendant processing. (see http://lists.xml.org/archives/xml-dev/200201/msg01867.html)

> (b) Even if it were, there is even today no way to declare an attribute as
> containing an "XPath expression" (or a "list of namespace prefixes", to take
> another example that XSLT uses).
> 
> A solution based on declaring those elements or attributes that contain
> namespace prefixes in their content might have been workable if it had been
> invented at the start. It now falls into the category of 20:20 hindsight.

I disagree with the characterisation as "hindsight" (see
http://lists.xml.org/archives/xml-dev/199808/msg00373.html, and
http://lists.xml.org/archives/xml-dev/199807/msg00067.html which,
although confused, was to the point.)

The categorization also does not address the question, which was why an
element needs the in-scope namespaces as a static value?

At the point where a document has been parsed, a DOM which binds
namespace names to prefixes strictly locally still provides sufficient
information to intern any qualified names present in the DOM at that
point. Once that is done, prefix-namespace bindings can be discarded.
Where any subsequent operations on the DOM which are restricted to
interned operands the cannot compromise the DOM's integrity. Given an
integrated DOM, it is possible to generate a document without regard to
the initial prefix-namespace bindings.

Given this behaviour, what purposes do static in-scope namespaces serve?




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS