[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enlightenment via avoiding the T-word
- From: Nicolas LEHUEN <nicolas.lehuen@ubicco.com>
- To: 'Rick Jelliffe' <ricko@allette.com.au>,"'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
- Date: Thu, 30 Aug 2001 10:57:03 +0200
> Did you want to repost this to the whole group? or is this private?
Well in fact I messed up with the reply button... But I'm going to reply to
your mail on the list.
>> only, because the name element would be locally defined
>within the person
>> global type. This way you could define a stylesheet for the
>"stuff" document
>> that imports a stylesheet for the "person" content-model. A
>local element
>> gets its semantic from its context, which by definition is the global
>> element in which it is defined (since a global element has no other
>> context).
>
>Potentially it could be local all the way up.
Well, the definition of a local element is that it is an element defined in
a schema in the context of a global element. A local element cannot be local
"all the way up". It can be buried deep inside a global element, but it must
have a context, which is the global element. The fully qualified name of
the global element <i>could</i> be considered as a namespace for the local
element (but here, we're entering another difficult subject which relates to
the qualified or unqualified form of local elements).
>> As for your third template, you write in the comment "our
>code is written to
>> just use the markup". This is the problem. Writing code
>without taking the
>> context into account doesn't scale up.
>>
>> Suppose that you have two persons in your order, the
>purchaser and the
>> seller. What will you do, just add new elements named
>> "purchaser-person-name" and "buyer-person-name" ? What if
>you want to write
>> an XSLT stylesheet with the same behaviour for both ? Or
>with different
>> behaviours for both ?
>
>Since the two name elements have the same general semantics, there is
>in fact no impact of context.
Well, if it REALLY had the same semantic, I would have made it a global
element, wouldn't I ? Just suppose the example I forged is meaningful,
please, though it's not easy :).
>> I would create a document like this :
>>
>> <purchase xmlns="...">
>> <buyer>
>> <person>
>> <name>Mr Smith</name>
>> </person>
>> </buyer>
>> <seller>
>> <person>
>> <name>Mr Johnson</name>
>> </person>
>> </seller>
>> </purchase>
>>
>> And if I want the same processing to occur I can write this
>template :
>>
>> <xsl:template match="person/name">
>>
>> that can even be imported from another XSLT stylesheet
>without having to
>> know anything about the purchase structure
>>
>> Whereas if I want different processing to occur I can write this :
>>
>> <xsl:template match="buyer/person/name">
>>
>> But you would never, NEVER write a template that matches a
>local element
>> wihout its context, because you would not be able to scale up.
>
>By eliminating the class "local elements" we make "would never" be
>"could never".
Nope. I can forge any example where a carefully defined global element name
within a particular namespace would require context inspection to
disambiguate its semantic. If I give you a "person-name" element, do you
know what to do with it immediatly ? No, you'll ask me for the context.
Okay, the context is a bill. This does not give you any information. Another
part of the context, is the "buyer". This gives you a lot more information.
You could then tell me "okay, so in order not to depend on the context, I'll
name the element buyer-person-name". In this case, let's imagine a phony
example where you are writing a bill that compensates (and mentions) other
bills. What's the buyer's person name ? You have to take the context into
account, unless you want to drop reusability and reinvent new element names
each time you try to compose two schemas.
>> >In any case, if you are saying that schema-processing a document to
>> >produce a PSVI requires no processing, I don't believe it.
>>
>> A PSVI does requires some processing. But if you already
>validate your
>> documents before processing them, I don't think the overhead
>would be so
>> big. I think validating a document, then throwing away all
>informations
>> gathered during validation, to then process the document, is
>a great waste
>> of energy. *If* you validate your documents, why not have
>the validator give
>> us the information it had to gather anyway ?
>
>You are assuming validation at recipient. I do not believe this is how
>most XML is used. Validation is used for outgoing QC and
>debugging, and rarely
>for incoming QA.
Can someone confirm this ? I would precisely say the contrary.
>> I am not saying that building a PSVI should be mandatory.
>
>But given that the push programming practise I mentioned is
>ubiquitous, you are.
No I'm not, see the other posts I made, push programming is easily done even
with context-sensitive data.
>If the sender of a document decides to make a local element
>type (that is not
>a restriction of the global type) then it creates fragility in
>user systems.
It only reveal fragility on fragile systems. It won't on robust systems.
>> I think the model you describe is not quite realistic. If you pass
>> information back to an element's parent, that means that you
>have built a
>> context (which is the stack of parent elements). In this
>case you can easily
>> select the right process to apply to your local element, the
>selection table
>> being changed depending on the context. Building a context
>AND applying
>> context-independent processes is not the thing I would do.
>
>Of course you can change your program, if you are notified
>that the schema
>has changed. But there is no system for notifying and
>blocking that the schema
>has changed (unless the new documents fail). If the new
>document does not
>fail validation, then the program keeps on working, sticking
>spurious data in
>unexpected places. Both failure and spurious data are signs
>of the fragility I
>am talking about.
Same as above, see my other posts.
>Whether you like it or not, if you look at most
>XSLT/OmniMark/Perl push scripts,
>they are written with the assumption that there is a
>particular order and semantics
>to an element name that will not change. A system written on
>the assumption that
>there are no local types is fragile when local types are introduced.
I agree at 100%. But we're not *introducing* local types here ; they are
already in use in the real world. As I've said before I don't think assuming
that an element name has a unique, context-insensitive meaning make writing
programs really simpler, because data processing is 90% of the time
context-dependent (regardless of the name of the elements).
>Cheers
>Rick