[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Differences of our binding/identifications propsals,possible settlement
It seems the differences between our proposals is are not that large. The reason is we won't define in our spec, how to refer to a remote document, anyway. It is up to the user / plugin, which IRI is being used. The remote document can be described by a created ID as you suggested tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067-B31D-00DD010662DA or a URL pointing to the document or any other IRI. I assume that the ID is only being used, when the document is final, otherwise the relation would broken too easily. It seems reasonable to suggest a common naming schema in an informative section. The following further differences we had in our proposals: - The type of the IDs, you recommend twice a UUID, I would rather use an IRI and a integer, is it fine to agree on two strings and suggest UUID informative? By this the URI as document ID with version as integer suffix would be still possible. - If I understand it right, you want to refer to internal IDs as well by tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067-B31D-00DD010662DA/content.xml#foo I suggest to facilitate this by exchanging the prefix for the internal resources of a package by odf:. Imagine someone have to exchange all IDs, when the document is being changed and saved. The ODF application does not want to mess with RDF application data. If someone parses the RDF data for external use, the prefix might be exchanged by some IDs (e.g. as you suggested) or a path/local URL. Leave it to the them. This would give us flexibility. If someone likes to argue that is not standard procedure, we can say it will become standard, similar as our ODF RDFa elements. Does this help? Svante
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]