[
Lists Home |
Date Index |
Thread Index
]
- From: "Ean R . Schuessler" <ean@novare.net>
- To: xml-dev@xml.org
- Date: Fri, 7 Apr 2000 16:05:22 -0500
On Thu, Apr 06, 2000 at 09:47:53AM -0400, David Megginson wrote:
> No more reliable, I shouldn't think, but (a) more transparent [good]
> and (b) more verbose [bad]. It was a judgement call, but I think that
> most of us on the WG didn't think that something like this would ever
> fly:
>
> <http..www.w3.org..1999..xhtml:html>
[snip]
> </http..www.w3.org..1999..xhtml:html>
>
> while we thought that something like this would
>
> <html xmlns="http://www.w3.org/1999/xhtml">
[snip]
> </html>
*Blush*
Yes, that was a good call. I guess, additionally, that the namespace binding
scheme gives you explicit scope which makes collisions managable.
> The thing is, 'date' will mean something different in each Namespace,
> so the filter should *only* operate on it in a specific Namespace. If
> you define an element {http://novare.net/ns/}date that means "whatever
> the current date is at time of processing", then the DateFilter should
> look for 'date' only in that Namespace (no matter what the document
> type).
>
> It's the same thing as Java packages -- you would write code that uses
> org.foo.stuff.Thingy, but you would never assume that a class named
> "Thingy" in any package (say, org.bar.hack.Thingy) is the same.
Hmmm. I'm still not sure if this answers my question. Lets say that my
document is going to be processed in several stages by seperate groups of
people. I've written a DateFilter that I've distributed to all these groups
but each one is going to use it in a different way. So, lets say that
marketing wants dates in their sections of the document fully spelled out
while engineering wants it in ISO format. So, what I want is something
like:
[ Reader ]
v
[ DateFilter, long mode, uri="http://marketing" prefix="marketing" ]
v
[ DateFilter, iso mode, uri="http://engineering" prefix="engineering" ]
v
[ Handler ]
Is that an ill concieved notion?
> In SAX, requests flow upstream and data flows downstream -- that's
> just the way we designed it. It keeps life very simple for
> implementors of client software, but it means that filters have to
> start with some kind of a reasonable default state and wait for an
> explicit request to change it, rather than going out and actively
> querying the client. That's a pretty normal approach -- JDBC drivers,
> for example, don't go out and query the client application either.
That is true. However, what I am talking about doesn't necessarily mean
that the flow has to be two way. You could have a method for delivering
metadata, like handler.property( String name, Object property ). Which
would be downstream. Or you could have some way for the Handler to get
its Parent (which I realize creates an odd conflict) so that it could
at least query up the stream for property information. Right now there
is no way for requests to flow upstream from the base of a SAX chain
becuase it terminates in a Handler.
Sorry for the somewhat naive line of questioning.
--
_______________________________________________________________________
Ean Schuessler Director of New Products and Technologies
Novare International Inc. The Unstoppable Fist of Digital Action
*** WARNING: This signature may contain jokes.
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|
