From EXPath

Jump to: navigation, search

New page dedicated to contain temporary comments of all natures (draft responses to comments, etc.)

Jostein Jacobsen

Comments about Jostein's comments on packaging, as part of the project daisy-pipeline.

  • a) In 2 Concepts, yes, good re-phrasing, and good idea to put a diagram to show the structure visually (even though it is simple, there's nothing as good as a diagram).
  • b) I don't agree with adding a version number at the component level, though. See below (3.* Component versions).
  • c) In 3.1 Overall structure, I think this is too much information. CPU and OS for instance are really not relevant. An XQuery module or XSLT stylesheet is not dependent on those (even though it is maybe possible to create a counter-example with an extension function, that is too much dedicated, and we don't want to encourage that); an XProc pipeline can be designed to be dependent on a system, but once again that is more cleanly addressed at the XProc level.
  • d) Some other infos make more sense, but yet, we have to keep in mind this is a low-level format to package a library in order to be usable automatically by a processor. I think we should restrict those infos to something like Project URI + License info + maybe a maintainer email address.
  • e) More precise infos are actually more relevant for a project like CXAN. As we have not defined yet exactly what info it needs, it is premature to define them in the packaging system. It can be implemented by adding a cxan.xml descriptor, and maybe, maybe be added in a future version if that makes sense, but a specific descriptor should fulfill perfectly the needs.
  • f) In particular the suggests and recommends really belong to a system like CXAN, where people test and define what sets of packages can work together (that's out of scope of the author of one single library).
  • g) About SemVer, yes that's a good idea. I remember now where I discovered this spec :-) Actually I wrote something very similar (like the attribute names are exactly the same :-p) on my way back from Montreal. I think you saw that thread. That proposal was less about syntax (I think a link to SemVer is probably better and more simple), and more about the behavior of processors, but I think we have the same idea. Please tell me if I missed something.
  • h) 3.* Component version (about adding a version number at the component level, in section 3). I don't think that's a good idea actually. The package must be seen as a whole. Like a Java class has no specific version number in a JAR file. The whole JAR file has a version number (or maybe even the project it is part of has a version number, and every JAR share the same version). If we try to be too much fine grained, I think we will just add some confusion...
  • i) In 4 Processor behavior (about The referenced file must be part of one of the declared dependencies). Well, that's a bit more complex than that. The final user code is not part of a package; for example a one-shot stylesheet written in an IDE, or just the Java code launching a transform from a package, identified by its public URI. The resolution in those cases does not make sense to refer to the "declared dependencies". When a URI is used in a package's component, then yes, that could make sense (even though it is easy in XProc to construct a stylesheet with a public URI dynamically created, resolved in the repo nonetheless...) Probably we can describe such a mechanism and say that an implementation SHOULD generate a warning, and maybe an error (the best behavior depends on the environment and on user options).
  • j) In 5 On-disk repository layout (about version number added to package dir), yes, that's an existing modif, not published yet :-)
  • k) In 6 Example, yes there is maybe a cleanup to do about package/module, but this is really a package there, not a module. Actually, the word module (in this context) is more legacy, and I wonder if we have to keep it. I feel it could be interesting in a later version if we want to create packages with several modules, but I am not sure. and the word is misleading, because of the XQuery usage of module.
  • l) About OASIS XML Catalogs, I actually got rid of them. They are at the same time too general (like resolving a prefix to several files) and too limited (cannot resolve the same URI to different components depending on its type: XQuery, XSLT, XProc, etc.) The on-disk repo layout now uses simply the package descriptor.
Personal tools