[Bug 4636] What should SML 3.3.1.1 say about fragment identifiers?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4636


kumarp@microsoft.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|cmsmcq@w3.org               |kumarp@microsoft.com
           Keywords|needsAgreement              |hasProposal




------- Comment #4 from kumarp@microsoft.com  2007-11-08 06:58 -------
I investigated the URI fragment issue by reading the relevant specs, MSDN
articles and other sources. Here is the summary of what I found.

We have 2 options:
1.      Define our own way of encoding fragment identifiers. This is defined in
an earlier comment, therefore I am not repeating it here.
a.      Pros:
i.      Simplicity
ii.     We fully control the definition.
iii.    Namespace binding context is same as that of the containing element.
This means that namespace binding can be reused across multiple references.
Increases the readability of a model.
iv.     Very little implementation impact since an SML validator already has to
support xpath 1.0.
b.      Cons:
i.      Politically wrong approach according to Michael.

2.      Use xpointer framework in combination with a profile of the xpath1
scheme.
a.      Pros:
i.      Politically right approach according to Michael
b.      Cons:
i.      We will take normative dependence on something that is not a W3C
recommendation.
(Michael to find out if this is allowed/discouraged by W3C. Not sure how it
balances against 2.a.i.)
ii.     xpath1 scheme allows full xpath 1.0 expressions plus some additional
extensions. We only need a limited ability to address elements. The WG needs to
spend time defining the profile.
iii.    We do not completely control the definition. Although we will create a
profile, the underlying definition can potentially change. The likelihood of
this is low but we cannot rule it out.
iv.     The xpath1 scheme normatively requires support for xmlns() scheme. The
namespace binding context must be set using xmlns() scheme. It cannot use the
namespace binding context of the containing element.
For example, even if xmlns:x=’http://x.com and xmlns:y=’http://y.com’ have been
defined for an element, if it uses xpath1 scheme (or other xpointer() schemes),
it must repeat the bindings as follows:

“<sml:uri>baseuri:/a/b.xml#xmlns(x=http://x.com) xmlns(y= http://y.com)
xpath1(/x:e1/y:e2)</sml:uri>”
compare that with:
“<sml:uri>baseuri:/a/b.xml#/x:e1/y:e2</sml:uri>”

The namespace bindings must be repeated for every xpointer instance. This can
quickly get very unreadable.
v.      To be fair, the above can be partially solved by using the
xmlns-local() scheme but that scheme is not a W3C rec. either.
vi.     Implementation impact:
1.      Must implement Xpointer framework related parsing (as defined by BNF in
the xpointer framework).
2.      Must implement Xpointer framework related escaping mechanism.
3.      Must implement xmlns() scheme.
4.      The Microsoft .net framework does not support any of the above, thus
has impact on the Microsoft SML implementation.

I have not considered some of the other options we discussed such as we forming
a sub-group to move xpath1 (or our own schme) through the W3C process to
recommendation. I think that introduces too much uncertainty on SML schedule.

Received on Thursday, 8 November 2007 06:58:17 UTC