XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 9:29 AM -0500 9/25/02, Michael McEniry wrote:
Elliotte Rusty Harold wrote:
>  I am exploring the API for base URLs. My current thinking is that there

Is your notion of a base URI distinct from the XML Base
(<http://www.w3.org/TR/xmlbase/>http://www.w3.org/TR/xmlbase/) 
recommendation? If so,
what does the value of a base URI mean?

It means the URI of the entity from which the node was loaded, unless 
an xml:base attribute or a call to setBaseURI changes it. Except for 
that last bit about setBaseURI, I think this is the same definition 
XML Base uses.


It seems reasonable for XOM to understand base URIs,
since more and more standards seem to be assuming they
exist. Will XOM grow to support XLink?


Probably not as a core part of the API. However, it should certainly 
be possible to wire understanding of XLinks into an application built 
on XOM. If you see anything that would stand in the way of that, I 
need to fix it. A couple of the sample programs do work with simple 
XLinks.

>  will be two methods in the Node class with the following signatures:

A base URI is scoped to an Element (and Document). The
value of a base URI predominantly used to qualify the
value of a (link) Attribute. Add these methods to
ParentNode, to cover Element and Document, and to
Attribute. It doesn't make sense for the various
LeafNode types to contain these methods.


Looking in the xml:base spec I see "Relative URIs appearing in an XML 
document are always resolved relative to either an element, a 
document entity, or an external entity. There is no provision for 
finer granularity, such as per-attribute, per-character, or 
per-entity base information. Neither internal entities, whether 
declared in the internal subset or in an external DTD, nor 
freestanding text (text not enclosed in an element) in an external 
entity, are considered to set a base URI separate from the base URI 
in scope for the entity reference."

That last sentence bothers me. I'm not sure it's appropriate to say 
that a text node can't have a different base than its parent element. 
However, if I did accept this, it would certainly simplify the 
implementation, and reopen the possibility of merging all text nodes 
(which separate base URIs for adjacent text nodes would foreclose). 
However, it would also reduce the expressiveness of XOM, but maybe 
not in an important way.


>  1. Should I make any checks that this is a legal URI? That is,
>  should I check that these values are syntactically correct URIs
>  according to RFC 2396? I do make these checks for namespace URIs, (which
>  is aggressive in itself) but here nothing you could put in this property
>  would make the document malformed.

Enforce URI syntax, as with namespace URIs. Least surprise
and all.

>  2. Should I allow relative URIs or only absolute URIs?

Accept only absolute URIs for base URIs. I think that's
what the XML Base recommendation says, I could be mistaken.

No, they do allow relative URLs. There's also the annoying question 
of allowing URIs or URI references.

>  3. Should I allow URIs at all, or should this just be a URL?

URIs will be more general, since not all resources need
to be "located". Imagine an application that supports
relative URIs for namespaces.

I think the only defined relative URIs are relative URLs. The real 
question is do I allow URNs or not?
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+