[
Lists Home |
Date Index |
Thread Index
]
Hi,
now I see what Eric means (see below), thanks to him. But what do you all
think about the following?
There is a lesson from OO: Don't let the code depend *too much* from what's
inside a certain *thing*.
If a developer writes code, that depends *too much* on whether there's
character data only or mixed content inside an element (another example: the
position of a subelement), then it's the failure of the developer, and not
of XML. (I produced this failure too ;-)
According to my experience it's possible with the DOM API to write code,
that won't break for a rather satisfying (I'm cautious) set of structural
modifications. But: The developer has to force himself. Another way to more
stable applications is XPath, as Elliotte Rusty Harold said in another post.
Mike Champion in another post:
> Hmmmm ... maybe combining the XML "expose the data, don't encapsulate it"
> meme with the OOP "bundle the code with the data" meme? I don't know ...
> the "classic" OO ideas aren't scaling to the web as well as markup is,
> but I'll bet that the "next wave" is forming out there somewhere in the
> nexus between code and data.
<sf>If I encapsulate an element's content by switching during processing to
an interface, that abstracts away - say - the structure inside, then it will
be easier to produce applications, that are less likely to break down. Does
anybody see a chance with today's tools?</sf>
<even-more-sf>Let's stay by the REST-architecture. I send a GET to a
resource, which has e.g. different structure inside suddenly. I process the
representation of the resource by means of a XML-application - which breaks
down or not. Does REST help here or has it nothing to do with the problem?
Are there some additional architectural constrains by which the web can be
enhanced to handle the problem? I ask, because I work inside an enterprise
network - big and world-wide but closed. May be we can enhance just (a part
of) our part of the web.</even-more-sf>
If you think, I'm going crazy - OK.
Greetings
Klaus
> Von: Eric van der Vlist <vdv@dyomedea.com>
> Datum: Tue, 05 Mar 2002 14:50:58 +0100
> An: xml-dev@lists.xml.org
> Betreff: Re: [xml-dev] XML doesn't deserve its "X".
>
>
> Klaus Backert wrote:
>
>>> If you also mean the ability to include new information in an existing
>>> vocabulary, I think that XML has failed so far
>>
>> Including new information into an existing vocabulary (= inserting character
>> data into an XML-document, which is built according to a problem-specific
>> language - do you mean this?) is part of my job (doing it by editor and by
>> own applications). No problems with this too. Could you specify how XML has
>> failed, please?
>
> That's the easy part :=) (meaning no offense)
>
> What's difficult is to extend it without having to predict what the
> needs will be (and where the document will have to be extended) and
> that's unfortunately the real challenge for real life open world
> applications.
>
> <snippet-from-another-answer>
> Let's take a simple example... I have a text only element:
>
> <ns1:foo>This is a simple example.</ns1:foo>
>
> If I extend this example to include a semantic element to identify
> "simple" as an adjective:
>
> <ns1:foo>This is a <ns2:adj>simple</ns2:adj> example.</ns1:foo>
>
> I am changing a text leaf node into a mixed content including 2 text
> nodes separated by a child element and this will likely break 90+% of
> the existing applications.
>
> The situation is probably better if you want to add an element in an
> elements only content model, but even in this case, if you take real
> life applications, how many of them will you break? 30%, 50%, 75% ? Way
> too many in any case!
> </snippet-from-another-answer>
>
> Eric
|
