Re: Enlightenment via avoiding the T-word

[Rick Jelliffe <ricko@allette.com.au>]

 From: "David Hunter" <david.hunter@mobileq.com>
 

> Wow.  This seems to me like a pretty hard-line stance.  Is it shared by
> many?  i.e., that <name> [in a particular namespace] means one thing and one
> thing only, and that if you want a "name" for something else, then you'd
> better find another label for the element that contains it?  

It should only have one _general_ meaning per namespace. 

> So, instead of 
> 
> <stuff>
>   <person>
>     <name>John</name>
>   </person>
>   <company>
>     <name>The Company</name>
>   </company>
> </stuff>
> 
> you should always have
> 
> <stuff>
>   <person>
>     <person-name>John</person-name>
>   </person>
>   <company>
>     <company-name>The Company</company-name>
>   </company>
> </stuff>
> 
> or some such?  

The first is fine. But if you were in Lloyds bank, and you used the
term name as local jargon for "partner", then that is a different  general
meaning.

>I myself, and probably others on the list, would have said
> the opposite is good practice - don't include the name of the parent element
> in the name of the child element.  (I do the same when designing databases,
> not that I do that too often.  I never include the table name in a column
> name.)

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?

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?
 
> So I guess I am most uncomfortable with the term "best practice" - I don't
> think that there is a whole lot of agreement on this issue, to put it
> mildly.
 
If you don't believe that some practises can be better than another, or that one
practise has ramifications which we need to tease out in order to judge which
route to take, or when to use one approach and when to take another, then
what do you suggest the alternative software engineering approach is?  
Passively accept whatever the big stakeholders shove down our throats 
and say "thank you"? 

When best practises establish themselves, then technologies get reformed
to encourage them and to drop support for bad practises.  Every specification-
developer has an implicit list of best practises by which they judge matters.

But specifications pretend not to; look at XML Schemas (or RELAX, maybe)
for example--do they give any indication of what they think attributes are
for?  We have this big fact of attributes in XML, and I don't see how any
schema language can be remotely credible without giving some explicit
treatment of what attributes are for.  (Schematron, for example, allows 
that attribtues can give the species while the generic identifier gives the
genus; or giving links which may be of certain types {i.e. the type of
 the target of a link may be constrained in someways by data
related to the anchor of a link: links do not need to work only from
ID to IDREF}).    


Cheers
Rick Jelliffe