RE: Enlightenment via avoiding the T-word

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

> 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