[sc34wg3] SAM issue: locator-notation-support

[Lars Marius Garshol]

* Martin Bryan
| 
| This depends on whether things with tags in are considered to be
| valid parts of strings or not. 

I think for the [reference] property of a locator it's acceptable to
have SGML markup in there; especially if that is basically part of the
locator notation's syntax.

| Most of the HyTime addresses have at least one level of embedded
| tagging. For things like FCS and lists you have a more complex
| substructure. For property values you have QPNs (qualified property
| names).  

This also sounds OK, even if the tagging may use SGML markup.

| Notations can suffer from the "valid character set" problem in that
| they might include control codes or reserved XML symbols. (Its
| year's since I went through all this stuff though!)

That's OK. The SAM says the value of this property is a Unicode
string, but places no restrictions on what characters are allowed
there. If we can't serialize such locators back to XML that's not
necessarily a problem, since HyTime locators wouldn't fit into XTM
anyway.

I think the trickiest part here is that SAM does not deal with
resource identity at all, but requires the locators to be compared to
determine identity, whereas HyTime really expects things to do be done
the other way around. It may be that we have to make some changes in
order to accomodate the HyTime view of resource identity.
 
* Steve Pepper
|
| The question is, is it enough to have a "HyTime" locator notation,
| or should we have several notations, one for each *kind* of HyTime
| locator (queryloc, treeloc, nameloc, etc.)?

* Martin Bryan
|
| I would prefer not to have them defined separately if we can get
| away without it, even if it meant restricting the list of permitted
| location types to those that can be defined using strings and
| stating in the text which elements those strings have been derived
| from for each of the types.

I agree. The question is whether a structure like this

  Locator(notation="HyTime", reference="<locator goes here>")

actually works in the sense that you can look a the locator string and
know how to interpret it (what kind of locator it is etc). Does anyone
know the answer to that?

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >