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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] RE: Namespaces Best Practice

[ simon responds... ]
> >Tree-trickery may not be possible in the context of stream
> >based processing.  Sometimes "minimizing the decls" isn't
> >an achievable goal.  You may end up adding a few decls
> >in case they're needed later, but it turns out they aren't.
> Sure.  What makes the work I'm doing now (which spun off the Regular 
> Fragmentations project) fun is that I'm mixing trees and streams.  Damming 
> the flow of events and creating structures, then releasing the dam and 
> letting the structures flow out as events again.

Yep, I like that model.  So long as nobody's subsidizing any
construction on the flood plain ... :)

> > > Finally, I don't think variable-scoping is a useful comparison for
> > > namespace-scoping in XML documents.
> >
> >I was going for accuracy in explaining the name binding rules.
> >Actually using those names is a different issue.
> I suppose, though I'm not sure quite how you think it adds accuracy.

Mostly by correcting some false assumptions I thought I was seeing.

> No, I'm suggested that variable scope in programs is much simpler than 
> namespace usage in documents, especially complex documents using things 
> like XLink or xsi:type.  The scopes inside of programs don't typically 
> cross-link that way, 

There seems to be a missing example here.  The things to which
variable names are bound certainly get arbitrarily complex, but
there's no difference in the scopes of the names themselves.

>          and you'd not normally think of defining variable 
> scopes at the beginning of the entire program.

No more than I think of defining namespace prefixes at the beginning
of XML documents, that's for sure!  Global variables are classic
examples of Things To Avoid, and I can't see any reason to treat
xmlns declarations any differently.

- Dave