[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Enlightenment via avoiding the T-word

  • From: Rick Jelliffe <ricko@a...>
  • To: xml-dev@l...
  • Date: Wed, 29 Aug 2001 12:34:27 +1000

one word company names
 From: "David Hunter" <david.hunter@m...>
 

> 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 


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.