RE: Enlightenment via avoiding the T-word

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

Rick wrote :

>Why is it more efficient to make the receiver of your tables 
>disambiguate the 
>names (by using a PSVI or XPath) than doing it when the data 
>is serialized?
>
>It is nice that every table is a separate namespace. But why 
>is there any need
>to complicate XML with all this extra levels of processing to 
>support that?

There is no extra level of processing. As I wrote before, in the first case
you have XPath expressions like /stuff/person/name/text(), and in the second
case you have /stuff/person/person-name/text().

I may be dense, but I don't think there are so many applications out there
that care about the person-name without caring about the person itself.
Context-independent processing may exist, but I think it is not as important
as all the context-sensitive processing that is done out there.

If you want to stick with the table/column metaphor, I don't know of any
relational data processing that care about a column without taking care of
the table it belongs to.

I'm really sorry, but I don't see what is the point of disambiguating names,
be it by context-based prefixing or by using namespaces. It does not change
anything in writing programs, and it does not improve readability by humans
(we are used to reading context-dependent documents, after all).

>If people agreed on name-mapping (munging) rules (e.g. at an extreme,
>that every table is a separate namespace, at a more reasonable 
>level, that
>serializing a report with ambiguous names, any ambiguous name 
>should be 
>formed by table_column. Lots of other possibilities that keeps 
>XML a nice
>s***** language for data interchange of reports, not some 
>hopeful monster
>giving an abstract information set for semistructured DBMS schemas) 
>then would we need PSVI processing much?

If you define a schema for a set of XML document, that means that you will
follow it when processing the documents. Why wouldn't you use PSVI as a
precious source of meta-information, that can provide modularization and
extensibility to both your schema and your processor ?

For example, you could associate processing blocks (classes or methods) to a
particular PSVI element, being able to add processing blocks in a
non-intrusive way, as new elements are added to the schema.

I haven't thoroughly read the PSVI spec from the W3C, since I found it
obscure. I'm just taking the abbreviation "PSVI" as its root meaning, which
is "Post Schema Validation Infoset", which is, to me, an infoset of the
original document, enriched by related schema information.

When processing a document, you can hardcode the processing path followed by
your program : "I first process the person, then the product, then the
delivery info". The problem with this approach is when you get to this :
"Uh-oh, what's this payment element ? I don't know how to handle this, so
let's skip it". With the PSVI plus a processing model associating schema
elements to processing blocks, you have a much greater extensibility, I
believe.

Regards,
Nicolas