[
Lists Home |
Date Index |
Thread Index
]
On Fri, Feb 01, 2002 at 03:13:36PM -0500, Jonathan Robie wrote:
> > #/root/foo[1]/bar[2]
> >
> > Just doesn't work as is because it doesn't allow for namespace support
> >and hence out of scope (or you put schemes in to allow binding namespace
> >prefixes to URI, possible but I don't remember anybody suggesting it).
>
> I think that XPointer already has a way of declaring namespaces:
>
> #xmlns(x=http://example.com/foo) xpointer(/x:root/x:foo[1]/x:bar[2])
FixPtr which is the most advanced replacement suggestion don't have
schemes. This is an XPointer subset. This could work (i.e. 2 conformance
level ... to be defined).
> > #1/2/3
> >
> >breaks as soon as an ancestor or any predecessor of those is modified
> >would work for really static content, but the maintainance cost looks ...
> >interesting
>
> Ah, but that's what you get for trying to create stable references into
> documents that change. If you want to guarantee that you can actually do
> that, you need identifiers in the referenced document, and these
> identifiers serve as a contract on behalf of the referenced document which
> has agreed to provide these addresses.
>
> If you don't have that guarantee from the referenced document, then there
> is no way to ever guarantee references will not break. XPointer has worked
> really hard to get as close as possible to being robust in the face of
> change, but it can still fall on its face when a document changes.
there is no garantee, right. but the thumblers mechanism is clearly
one of the most unreliable, it really easilly break.
> > If you think that
> > #foo
> >is simple and fast, yes in a very well defined context, in general it's
> >an horrible solution, you have to rely on something outside the document
> >itself to simply make that request. //*[@id=foo] at least can work directly
> >on the document.
>
> I'm not sure what semantics you intend for the above syntax. Suppose the
> meaning of #foo is identical to the following XPath expression:
>
> //*[@xml:id="foo"]
>
> That seems cheap and effective. At any rate, I have not studied this
I would *love* to have xml:id ... I have tried twice already, there is
only so much pain one can take while trying to get something fixed. Go
ahead ...
> particular problem extensively, but at first blush, any one of the three
> solutions you consider unworkable seems reasonable. The middle one seems
all of these solution can "work" in a given context. the problem
is that if you want to define the fragment ID for XML you'd better have
a solution which work for most context.
> Let me be clear though, I think that full-fledged hypertext along the lines
> of the original XPointer vision is a good thing, and I am not at all saying
> it should not exist. I am, however, saying I do not believe it should own
> the fragment identifier for XML. That should be reserved for a very simple
> and efficient kind of pointer.
What is the most proeminent point for a spec. Doing it's job well
or being very efficient in all cases ? Open question to me. Would XML
has had success if it was the stripped down version that SML activist
(used to ?) push for. XPointer as XLink is document oriented, that was
the charter of the group I think. You can revisit this and say
that text/xml and application/xml should have different fragment
identifiers (XPointer in the first case and some simpler proposal for
the latter), well that could be one way to clearly differenciate both
Mime-Types in the mind of the public, why not.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
