Re: Swamped (Was:Re: Call the question!)

Thank you Joe!  This was *very* Helpful.

On Mon, 22 May 2000, Simon St.Laurent wrote:
> At 04:43 PM 5/22/00 -0400, keshlam@us.ibm.com wrote:
> >OPTION 3: TREAT NAMESPACE NAMES AS LITERALS.
> >^: Some of the other specs (eg XPath?) which reference Namespaces would
> >need to be rewritten to reflect this understanding. Others already have
> >this behavior.
> 
> On this last bit, I'm not sure that they would need to be rewritten beyond
> making explicit that their behavior goes beyond what's specified in
> 'Namespaces in XML'.

I really think that having "namespace" related behavior 
littered through other specifcations (like XPath) is 
a recipie for confusion, possibly even inconsistency,
or worse, loss of production...
  
A.  I can have two reasonable readings of the XPath
    spec with regard to the namespace for "att", as

       <pre:el xmlns:pre="x" att="val" /> 

    In my literal reading, the NS spec's expanded name 
    for the attribute is { "x" , "el", "val" }, as
    it is in the per-element partition; however, the
    XPath spec talks about the namespace part and the
    local name part; in which case, the namespace 
    for the attribute, is ... "x"

    However, James Clark implemented it as.... ""

B.  What happens if my XML parser follows the XML 
    spec perfectly; and now I'm re-defining XPATH 
    specific behavior?  This leaves my SAX/DOM code
    different than my XPath code.  This is bad news.

   Luckly, it is possible to build the XPath 
   verision of namespaces on top of a good NS aware
   parser... however, we just have to know what to 
   discard; for instance if the "element" is filled
   in for an attribute, ignore the "namespace" value.
   How's that for confusing?

IMHO, no matter what the result here; the XPath 
and DOM specs should *refer* to the NS spec and
the operator (identity) defined therein.  It should
not be in the business of building a specific version
of namespaces for its own use...  

BTW, the blatant drop of per-element-partition 
knowlege from the XPath perspective makes me
wonder if we shouln't axe that part of the
Namespace spec while were up here debating it.
I personally agree with James Clark's interpertation
for the namespace of "att" in the example above.
If one is really interested in the namespace of
the parent element... get-namespace(parent())

Best,

Clark

Received on Monday, 22 May 2000 18:43:07 UTC