[
Lists Home |
Date Index |
Thread Index
]
- To: "Arjun Ray" <aray@nyct.net>,<xml-dev@lists.xml.org>
- Subject: RE: [xml-dev] Underwhelmed (WAS: [xml-dev] XOM micro tutorial)
- From: "Dare Obasanjo" <dareo@microsoft.com>
- Date: Wed, 25 Sep 2002 09:45:10 -0700
- Thread-index: AcJkciUzJ8EwYwSoSbuHeJuMlGnVBQAPqnJA
- Thread-topic: [xml-dev] Underwhelmed (WAS: [xml-dev] XOM micro tutorial)
From your statements I assume you are not a software developer or at
least have little experience writing parsers or related APIs. Your
arguments basically boil down to you admitting not knowing how to
implement this feature and thus decreeing that it is an "undecidable"
problem. As if parsing an XML substring and inserting into a DOM node is
like solving the Halting Problem.
Considering that I implemented similar functionality for SiXDML while I
was in school and I'm not even a developer at Microsoft makes me
seriously doubt you have any idea what you are talking about.
As for validity (as opposed to well-formedness), that is a problem
because IDs could potentially inserted into the subtree and then the
equivalent of a reparse of the entire document or some sort of lookup
table is needed. I need to go ask one of our devs if we actually support
that scenario or not.
--
PITHY WORDS OF WISDOM
Self-made people have an abundance of working parts.
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>
> -----Original Message-----
> From: Arjun Ray [mailto:aray@nyct.net]
> Sent: Wednesday, September 25, 2002 1:57 AM
> To: xml-dev@lists.xml.org
>
> "Aaron Skonnard" <aarons@develop.com> wrote:
>
> | Why isn't validity decidable?
>
> Because in the general case, you don't know what to parse,
> because you don't know when to parse. The string could
> change at any time. Your obvious strategy would be to simply
> cache the string, never parsing it until and unless forced to
> (say, if the "InnerXML" of some part inside were requested).
> If no such parse-forcing accesses occur, you can simply dump
> to output the the cached result of input string operations.
>
> We've already noted that something like
>
> foo.InnerXML="<bar>blah1<quux>blah2"
>
> causes some kind of dwimming to occur. Suppose this were followed by
>
> foo.InnerXML= foo.InnerXML + " blah3</quux>"
>
> and then foo.print (or whatever the "dump to output" call
> is). Will there be a "</quux>" after "blah2"? If not, why
> not? Wasn't then the first assignment parsed? If you
> interpolate a read of foo.bar.quux.InnerXML before the append
> and dump to output, is there a difference?
>
> I'd be very surprised if the internals weren't string-based
> with "lazy"
> parsing.
>
> | You may not like such features for reasons related to "purity"
>
> Purity has nothing to do with it. Clue has everything to do with it.
>
> | but that's not going to stop the hoards of Microsoft
> developers from
> | using them to increase productivity and get the job done.
>
> Don't I know that! I have the perfect sig for you. ;-)
>
> --
> Moronization: a form of acculturation where people are
> encouraged to anoint themselves with the supposed benefits of
> a technology without understanding the engineering (or lack thereof.)
>
> -----------------------------------------------------------------
> 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>
>
>
|