[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Public Comment
Comment from: ehennum@us.ibm.com
Esteemed TC members:
I'd like to offer a concern about the proposal
to move to an XPointer for fragment locations.
Hoping that's interesting,
Erik Hennum
> > 1. General practice for addressing....
>
> The issue here is that in an XML processing context there is only one
> *standard* for representing addresses of components within documents,
> namely XPointer....
>
> The XPointer spec provides a formal syntax for declaring the addressing
> scheme you're using for fragment identifiers, e.g.:
>
> foo.xml#xpointer(/bar/baz)
>
> In this case we know without question that "/bar/baz" is in fact an
> XPath addressing the "baz" children of the document root, if it is named
> "bar".
As Eliot remarked in another context, the problem is that the XPointer format
is good for processing but not for authoring.
First, a clarification. The DITA fragment locator is similar to the DTD ID construct but has to be unique
within the topic instead of the entire document. So, if foo.xml resembles
<topic id="foo">
...
<body>
<p id="bar">
<ph id="baz">...</ph>
...
</p>
...
</topic>
The DITA fragment to address the phrase is
foo/baz
The same address could be expressed in XPath (with complexity
that could be hidden by tools):
*[id='foo']//*[id='baz']
The concern would be in restricting the authored address to that
subset of XPath. If any XPath expression were allowed, the phrase
might be specified as follows:
topic[id='foo']/body/p/ph[id='baz']
While a valid XPath expression, that form would be fragile. An edit
of the topic (such as turning the topic into a concept or moving the
paragraph content into an item within a list) could preserve the phrase
and still break the reference to the phrase.
If XPath would need to be restricted, XPointer would require even
more restriction. A string range, for instance, would never be a valid
fragment.
If XML had a mechanism for declaring an ID as
uniquely scoped to a parent element, that would meet
the need. Would it make sense for the TC to propose
this enhancement for XML Schema?
Regarding putting the file reference and fragment into different
attributes, does that provide minimal simplification of the
processing (avoiding splitting the string at the hash) at the expense
of complication of the authoring? For instance, you wouldn't be
able to copy, paste, and edit an address as a single value.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]