DR 09-0172 ? WML: Filename-to-IRI mapping

[Chris Rae]

I'm suspect the honest truth of the matter is that this type of content in this field was superseded before there were any Office versions that used anything other than straight DOS file paths (bear in mind that DOS file paths exist here in Transitional only). Other paths can be represented in INCLUDEPICTURE using IRIs.

Chris

-----Original Message-----
From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp] 
Sent: 18 November 2010 13:46
To: e-SC34-WG4 at ecma-international.org
Subject: Re: DR 09-0172 ? WML: Filename-to-IRI mapping

Chris,

Then, why doesn't INCLUDEPICTURE also allow ny other system-specific path on any other system?

Cheers,
Makoto

> Hi Murata-san - I think the other instances you found are actually not the same thing. They're all examples of system-specific file path notation - so, for example, using MS products, you could use \\server\share\filename.ext on a Windows machine, or /home/users/chris/filename.ext on a Mac. Likewise you could use any other system-specific path on any other system.
> 
> I think the example in 17.16.5.27 specifically covers "DOS file paths" rather than system-specific paths.
> 
> Chris
> 
> -----Original Message-----
> From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
> Sent: 15 November 2010 20:53
> To: e-SC34-WG4 at ecma-international.org
> Subject: Re: DR 09-0172 ? WML: Filename-to-IRI mapping
> 
> Chris,
> 
> > This is one we were almost done with - it covers the napping of filenames to IRIs. 
> >We were agreed on the solution to the core DR, but we noticed in 
> >Tokyo that there was no normative definition anywhere for "DOS 
> >filenames". I was tasked with investigating.
> > 
> > I have investigated, and there appears not to be a definition 
> >anywhere in Part 4 (or Part 1). I propose we fix this by adding the 
> >term to "Terms and Definitions" in Part 4 (it is used twice in the 
> >part). I'm defining it using an EBNF.
> 
> Your solution looks great to me.  But I have to point out that a different solution, namely an undefined term "system-specific file path notation", has been used for three attributes in Part 1.  For example:
> 
> 	18.13.1  connection (Connection) 
> 	....
> 	sourceFile (Source File Name)
> 
> 	Path to the text file to use to import external data. Can be
> 	expressed in URI or system-specific file path notation. 
> 	 
> 	[Note: Applications can decide what forms of URI they support,
> 	and whether system-specific file path notations are supported.
> 	end note]
> 	   
> 	The possible values for this attribute are defined by the
> 	ST_Xstring simple type 
> 	(ァ22.9.2.19). 
> 
> The other attributes are:
> 
> @odcFile (Connection File) in 18.13.1  connection (Connection) 
> @sourceFile (Source File Name) in 18.13.12  textPr (Text Import 
> Settings)
> 
> I do believe that your proposed solution is much nicer.  Why don't we adopt the same solution for these three attributes?
> 
> Hmm, it appears that Part 1 has some examples of the DOS path notation. 
> Should we do the same thing for them?
> 
> @connection of dbPr
> 
> @w:val of w:query
> 
> @destinationFile of webPublishItem
> 
> @localConnection of olapPr
> 
> linkLocation of 18.17.7.145  HYPERLINK
> 
> @schemaLocation of schema
> 
> @odcFile of connection
> 
> @sourceFile of textPr
> 
> @Target of Relationship
> 
> Cheers,
> Makoto