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

RE: XNRL

  • From: Jonathan Borden <jborden@m...>
  • To: Uche Ogbuji <uche.ogbuji@f...>, Tim Bray <tbray@t...>
  • Date: Mon, 01 Jan 2001 13:53:39 -0500

xnrl
Uche Ogbuji wrote:
>
>
> 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).

	Yeah actually I agree which is why I am now allowing for the new "resource"
element to be either in the head or body.
>
> 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>.

	The "href" vs. "xlink:href" issue is a real problem. I'm also not too fond
of overloading "div" as I expect it will be confusing. A benefit of putting
all the resources in the header is maintainability. A benefit of placing
resource links in the body is the ability to individually document each
resource, so let the user choose. From the point of software, all you need
to do is ignore everything except a "resource" tag...

	You also suggested that we should emphasize that any resource, not just
schemata be included, hence the name "resource".

>
> 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.

	Don't get too caught up in this particular use of arcrole, remember that
these resources are defining the XML Namespace Catalog format itself... I
was just looking for a known URI to say: "XSD", "DTD" "RDFS" etc. In fact,
if you don't like these names, in RDF speak:

	<Class ID="XSD">
		<subClassOf resource="... the W3C URI"/>
	</Class>

and now you have "http://uche.org/names/#XSD"

The *only* thing that is important about the arcrole and role URIs is that
software knows what to do with the value. i.e. that when I want an XSD, I
look for xlink:arcrole="...#XSD"

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org


  • References:
    • Re: XNRL
      • From: Uche Ogbuji <uche.ogbuji@f...>

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.