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

Re: XNRL

• From: Uche Ogbuji <uche.ogbuji@f...>
• To: Tim Bray <tbray@t...>
• Date: Mon, 01 Jan 2001 08:50:55 -0700 (MST)

Starting out the New Year with duelling namespace resource specs?  And one
of them in full W3C dress with German examples.  Sign of the new year?

Anyways, my preferences lie somewhere between Jonathan's and Tim's ideas
(though I will not be putting up my own proposal).

First of all, I do prefer using <link> rather than <div>.  I hear Tim
saying

> 2. If you overload <link>, you get into difficulties with
>    href= vs xlink:href=... - due to parts of the design of
>    namespaces and xlink that make several people uncomfortable,
>    but the problem is there.

I must have missed a flame-war somewhere, but I'm guessing this is the
global attribute vs. per-element-type partition confusion.  Well in this
area I personally don't have a problem with
REC-xml-names so it's hard for me to judge the damage.  Strictly from the
point of "least surprise" wrt the element used, however, I'd vote <link>.

I'm not sure how I feel about the ability to use nested references as
demostrated by Tim.

I do think Tim makes more appropriate use of xlink:role and xlink:arcrole.
That's one thing that really bugged me about Jonathan's proposal.  I don't
think the idea of pointing to the schema of a reference is all that
important.  The reference doc will itself inticate its schema, possibly
through cascaded Namespace Resource descriptors.

As for naming, all I can say about "XNRL" is "bleeeech".  I'm pretty tired
of X???L in general.  I wish we'd use more evocative and even creative names.
After all, we're supposed to be semantic wizards, n'est ce pas?

I prefer "Namespace Catalogues" regardless of any association with FPI
catalogues.  Maybe "Namespace Descriptors", "Namespace Abstracts",
"Namespace Resource Guide", even "Namespace Brochures" (interest-free 'till
2003).  My literary side suggests "Namespace Precis".  K.  So I'm getting
silly.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@f...               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python

• Follow-Ups:
  • RE: XNRL
    • From: Jonathan Borden <jborden@m...>

• Prev by Date: Plan A + Plan B = Plan C?
• Next by Date: Namespace related-resource bundles: just the one?
• Previous by thread: Re: XNRL
• Next by thread: RE: XNRL
• Index(es):
  • Date
  • Thread