Subject: [arcmedia] [DISCUSS] archive fragment identifiers

From: Stian Soiland-Reyes <[email-masked]>
Date: Mon, 29 Jun 2015 13:32:19 +0100

http://archive-tlmt.github.io/arcmedia/arcmedia/#rfc.section.7

was added as my suggested text for fragment identifiers.

As i said, to foster discussion it is a bit 'brave' in that it is not
the usual "Nothing defined, we don't care" - but defines a standard
behaviour for any fragment identifiers that start with #/ - leaving
anything else open for individual registrations.

This mean that for archive/file or archive/* there would still be an
interpretation for fragment identifiers that would be very useful for
several purposes:

1) For semantic description of resources within any type of archive
2) For telling an archive tool to highlight a particular file
3) Giving a good default for registrations - e.g. compare with
application/zip which strangely do not define any fragment identifier.

*) ) But not their own subresources

q1:
Should fragment identifiers be exemplified always with the trailing #?
The current text is not consistent here. (The # is not formally part
of the URI fragment identifier - and fragments could be used outside
URIs)

q2: Should registration be allowed to specify that they do NOT support
#/* ? I am not sure of any use-cases - say a dmg file without any
readable file system.  The question here is if those use cases really
should be archive/* at all.

q3: What to call the #/ Pattern? I called it "Resource Path", but it
is a bit unclear still that the rest of the paragraph only specifies
the #/ pattern rules.

q4: case (in)sensitivity might need to be specified - e.g. preferred lowercase?

q5: Is the encoding paragraph precise enough?
(I want to mandate UTF8 where possible to make it IRI-compatible --
which means there could be many archives (zip, tar) where you only
know the bytes of a filename and have no idea about which file name
encoding was used on the system that made it -- there could even be
archives with mixed encoding..  registrations could however use the
non-/ fragments to access these)

Any other thoughts?

-- 
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/    http://orcid.org/0000-0001-9842-9718