W3C home > Mailing lists > Public > www-tag@w3.org > November 2002

Re: [Issue fragmentInXML-28] Use of fragment identifiers in XML

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Mon, 4 Nov 2002 21:06:04 -0500
To: www-tag@w3.org
Message-ID: <r01050400-1021-240B12FEF06311D6870B0003937A08C2@[192.168.124.21]>

Paul Prescod writes:
>It seems to me that the poor #-sign is a hammer and everyone sees it as 
>the tool for hammering their favourite nail.

I think you're completely correct about that, and a lot of the
motivation for writing the Internet-Drafts I published last week is
figuring out what kind of hammer the fragment identifier really is.  I'm
moderately astounded that I've not had more explicit pushback on those
drafts, though I've had a fair number of typos reported.

My current suspicion is that URI references are now grossly overloaded,
and that treating them only as a shorthand syntax for something more
explicitly specified might be a good idea.  For example:

http://www.w3.org/TR/REC-xml#sec-cdata-sect

Is typically interpreted as having meaning somewhat like:

<URIref>
   <!--URI could itself be broken down into parts-->
   <URI>http://www.w3.org/TR/REC-xml</URI>
   <Action>GET</Action>
   <Content-type>text/html</Content-type>
   <lang>en</lang>
   <location>sec-cdata-sect</location>
</URIref>

Whether or not they know those details, I suspect that's pretty much the
expections people have.  Change any of those expectations, and you
either need to supplement the URI reference with something else, or do
something like XPointer with its schemes.

I might want to reference the same point in the XML version as:
<URIref>
   <URI>http://www.w3.org/TR/REC-xml</URI>
   <Action>GET</Action>
   <Content-type>application/xml</Content-type>
   <lang>en</lang>
   <location>sec-cdata-sect</location>
</URIref>

A more sophisticated XPointer approach to a similar reference in a
document without labels might look like:
<URIref>
  <URI>http://www.w3.org/TR/REC-xml</URI>
  <Action>GET</Action>
  <Content-type>application/xml</Content-type>
  <lang>en</lang>
  <location>
    <nsContext>
    <ns><prefix>do</prefix><uri>http://simonstl.com/ns/do</uri></ns>
    <ns><prefix>re</prefix><uri>http://simonstl.com/ns/re</uri></ns>
    <ns><prefix>mi</prefix><uri>http://simonstl.com/ns/mi</uri></ns>
    </nsContext>
    <xpath1>//do:note/re:notes/mi:notes</xpath1>
   </location>
</URIref>

Or perhaps, to leap completely into the wild:
<URIref>
  <URI>http://www.w3.org/TR/REC-xml</URI>
  <Action>POST</Action>
  <Message>
     <message><craving>fire</craving></message> 
  </Message>
  <result>
      <Content-type>application/xml</Content-type>
      <lang>en</lang>
      <location>
        <requirements>
          <xinclude fallback="yes"/>
          <extEntities />
        </requirements>
        <nsContext>
        <ns><prefix>do</prefix><uri>http://simonstl.com/ns/do</uri></ns>
        <ns><prefix>re</prefix><uri>http://simonstl.com/ns/re</uri></ns>
        <ns><prefix>mi</prefix><uri>http://simonstl.com/ns/mi</uri></ns>
        </nsContext>
        <firstOf>
          <xpointer>string-range(//title,"Flames Ablaze!")</xpointer>
          <anyOf>
            <text>fire</text>
            <xpath1>//do:home/re:hearth/mi:fire</xpath1>
          </anyOf>
        </firstOf>  
      </location>
  </result>
  <result>
    <Content-type>application/xhtml+xml</Content-type>
    <Content-type>text/html</Content-type>
    <lang>en</lang>
    <location>
      <name>firePlace</name>
    </location>
  </result>
</URIref>

These things just aren't expressable in a URI reference (and probably
should not be).  It may be worth asking what kind of task is being
performed, and decide whether a URI reference is actually the best way
to get there.  

(And here I thought XLink was verbose... but at least that's reasonably
clear, except perhaps to the extent that it uses URI references.)


-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
Received on Monday, 4 November 2002 21:06:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:12 GMT